Since our "Planning for Apostrophe 3.0" post, we became a stand-alone company and we're laser-focused on getting Apostrophe 3 out. It's a great time to look back on what we talked about initially and see where we stand. First up, the UI update.
One of the greatest opportunities of a software's new major version is the opportunity to create a completely new user interface. We can rethink and rebuild what wasn't working well enough and maybe even add features that we've wanted for a long time. As mentioned in the original Apos 3 post, we started by cataloging the UX/UI issues in Apostrophe 2.x. That review became Github issues. Those issues contributed to an internal component punch list. That punch list has been methodically winnowed down as components are built into real, clickable web things!
Let's take a look at some of those web things. Note: these aren't designs, they're fully built front end components. Progress! (Spoiler: these are all online for you to try out already. The link is at the bottom of the post, but do take this journey with me if you would.)
Form inputs are the heart of any CMS's interface. They are mostly simple things, but they make a huge difference. The 2.x inputs are good, but they are getting a refresh as Vue components, ready to handle a multitude of use cases.
First, some examples of the existing, 2.x inputs:
Totally solid, but we can improve. Here are a few of the new input UI (beware: blinking gifs ahead):
We promise they don't change themselves constantly like that.
There are a few things to point out here. First, many of the inputs are more condensed. The radio and checkboxes are especially leaner. The boolean is also no longer a select field with two options as it is in 2.x, but instead a more obvious toggle-style element. Secondly, the color palette is updated. It's a small thing that makes a big difference. We like it.
Speaking of colors, the buttons show this off well, with a few different styles:
More complex UI
Inputs are great. I love inputs. You love inputs. But a CMS cannot work with inputs alone. Let's highlight a few favorites so far.
An in-context editor lives and dies by its widget menu. The current 2.x menu is a very simple vertical list of options. With too many options, it can go off-screen, requiring scrolling and preventing editors from having their options close at hand. This can be troublesome enough that in the Open Museum demo we used custom CSS to split the area widget options into columns.
The new area menu is a huge leap into the future, allowing grouping and reducing a bit of white space.
Much of Apostrophe content editing happens in-context, but that doesn't work for everything. Those things need modals, and we have updated UI for those as well. The modal component demo doesn't represent the final editor experience, but you'll get a nice picture of it here:
That placeholder text (e.g., "I am on the right", "I am the footer") are Vue slots that will contain everything from utility fields to tabbing UI and more. The "slot" feature of Vue is very helpful while building out a flexible interface like this.
There's also a slide-out modal style for some particular situations.
That's a small taste of the UI work so far. To name a few more, there's a join input with slat list UI, tagging menu, breadcrumbs, and, my personal favorite, loading dots animation.
Gifs are cool, but playing with a UI yourself is even more fun. We're using Vue-flavored Storybook, a "UI development environment" tool, to build and present each piece of the interface as components in order to help make them as reusable and maintainable as possible. Fortunately, the Apostrophe Storybook is public and online: https://apostrophecms.github.io/apostrophe-storybook!
As you are trying things out, pay attention to the element with options to see different states (such as the buttons) using Storybook's "knobs" feature. Please give it a try, check in occasionally for updates, and create a Github issue for UI elements if you see something that should be improved.
We're enjoying bringing the designs to life as attractive and fun components, but there's more happening under the hood. First of all, accessibility is a main consideration in all of this work. We've put a lot of work into making the UI elements work well with keyboard controls, as well as using semantic HTML and HTML roles to make it all more accessible. This is an ongoing effort.
Flexibility and extensibility are other important aspects of this work. One reason why we're using a modern front end framework (Vue) is to make it easier for other developers to contribute to the UI via new modules or project-level code.
There's still a lot of UI to build out, but with things like modals, menus, and inputs ready for action, we're pretty close to connecting all of this to the back end APIs. Tom has talked a lot about that latter part in the Discord chat and we invite you to join us there. And keep watching the blog here, as we'll be updating a bit more often here as we continue work.