Design/UX Audit and Recommendations

[rickmanelius]

What happened (or feature request):

• We jumped right into prototyping without extensively working through the wireframes and design processes. This has become a bit of a sticking point because it required @andrew-c-tran to fill in gaps without proper guidance. We've since opened an issue that tracks the historical conversation.
• Midflight @andrew-c-tran and I worked on hand drawn wireframes https://github.com/drud/ddev-ui/issues/15#issuecomment-338748893. This caused a bit of a rework and ultimately bottlenecked of PRs.
• Finally, we decided to get ddev-ui to a near feature parity with ddev-cli so that it was at least functional so that we could review the foundational elements and get the design and UX issues hammered out alongside testing and so forth.

What you expected to happen:

As we look forward both in our ddev-ui project AND our company processes as it pertains to design/UX/FEE, we are wanting to audit our existing project and address the current deficiencies around our wireframes, comps, style guides and get a robust process moving forward. Some of this was discussed during our ddev-ui expectations discussion.

What we are specifically looking for:

• [ ] Testing the DDEV-UI application as it stands in v0.2.0
• [ ] Review of alternative projects in the Drupal and WordPress landscape.
• [ ] Review of stakeholders for the UI (as opposed to the CLI).
• [ ] Generate a series of recommendations across style, layout, experience, etc.
• [ ] Review with the team (@andrew-c-tran @rfay @rickmanelius) and generate a roadmap with a punchlist regarding which items we're willing to commit to against an approximate timeline.

[aManNamedJed]

I have had the opportunity to do a run through of all of the basic functionality of the site, though haven't spent a ton of time really trying to dig down and break pieces yet. Overall, it appears at face-value that everything is working under the hood. Really I feel that where I can contribute the most here is my general reactions to the user experience and how I feel like we can make this better.

• Let's ditch the black. All of it. My immediate reaction is the heaviness of the black throughout the application. I feel like we should scrap all of it. I understand black is in the brand, but it's saturating the design and really weighing it down. We should never use the blue text on the black background.
• Way more whitespace, if possible. The app feels pretty compact right now, but any way that we can lighten things up and provide space will make things feel cleaner and more organized. The only white is within the cards, which only contain the logos. I really think we should go white everywhere and keep it really, really "light" feeling.
• The cards are cool in concept, but may not be practical. I know this has been done ad hoc, but we need to re-think how these are going to lay out. If I am really busy at an agency, I may have to bounce around from project to project, and may not turn off my container every time. If you have more than a half-dozen websites going, then scrolling to find the site feels clunky. I think we should at least provide the option to toggle between cards and table to display project.
• Modals feel clunky. Let's just create new "views" for any place where there is a modal within the app, so basically have a Project "view" that we display with all of the project information in it when we click the info button. I think just giving the user the information they requested right away without the half-second delay from the modal is what's bothering me. :neckbeard: It's maddening having to wait for a modal to go to MailHog
• Let's plan for this thing expanding and growing earlier than later. I could see this tool growing very robust, so I want to think about that now. We need to plan a layout that is extendable so we don't need to re-invent our design every time. Right now the application is very one-dimensional, focused on the management of projects, which is great, but I could see this having other uses later and I want to facilitate its expansion.
• I really don't love the use of Montserrat. The font is a little thin, though I feel like this also might be an issue of the blue-on-black text.

I think a great use of time would be to let me take a stab at a mockup to iron out how I feel like this could look, keeping in mind that we don't want to scrap the functionality that's currently there and functional. I feel like if we could get a mockup approved as the target, then it would be easier to chunk out the work that remains and really map out how we get there. All in all I think I can help make this way better with just a little TLC, mostly with just changes to styles and markup.

[aManNamedJed]

DDEV-GUI.pdf

Branding

I feel as though using the serif fonts can be a challenge in tech, but both http://rubyonrails.org/ and https://basecamp.com/ do it really well, so that’s ultimately the feeling I am trying to portray. Cutting edge, but dependable and professional. I changed the logo from PNG to vector so it will look really sharp on every device, even Retina display. I did add a couple of colors: the red-orange for our danger alert color, and then the slight tint on the dark blue brand base to give it that material/paper sense of realism.

But where’s the cards? Where’s the list?

I went into this fully intent on creating a view for All Projects where it had a component where users could view all of their existing projects, including a toggle between cards and a list. After speaking with Andrew about it, I realized it seems redundant to have this really handy sidebar where everything is readily available, and then a separate view right next to it with a list of every every project. Why not just show everything in the sidebar?

The gears started turning here and I got really excited because I really feel like there’s a lot of benefits to doing things this way.

The Benefits of the Sidebar Design

We were concerned about the number of projects and users needing to scroll, but I realized that Slack had already solved this issue. While sidebars are used by almost everyone and have become perhaps a little too common (WordPress, Slack, Shopify, Asana, etc.), they’re used so heavily for a reason: they’re extremely functional.

With this design, whether a user has a single project or 20, the sidebar will never look empty. Additionally, as our application continues to grow, we can just add a new menu item to a new “view” within the app, rather than have to re-think the design again. Users will also be able to resize the application window pretty freely, just like Slack.

[rickmanelius]

Reviewing this now. A couple things that I'll also consider in my responses, which may have been addressed and I fully understand that. I'm just stating that up front in case some of my feedback seems like it's coming from left field:

• DDEV Local to Live transition. One of the things that I really liked was the concept of the branding and potentially even the experience between the local dev tool and hosting to be somewhat seemless. For example, wouldn't it be sweet to have a local site and then click a button to "make it live" and send it to a dev/stage environment in our hosting? There would be billing and other implications, but this would actually serve as a mechanism to prompt a user to create an account and gives us a way to highlight our hosting offering.
• Sidebar. If we take the hosting conversation further, there are other items that can be surfaced in a sidebar from a management/settings perspective. I could connect to multiple hosting providers, handle permissions, etc. What about backups and revert from saved?
• Comparisons. While Bacecamp and Ruby on Rails were surfaced, I would like to see what you're thinking becomes after you take a peek at other local dev tools (Kalabox, Kitematic) and hosting dashboards (Pantheon, Acquia, Platform.sh) to get a sense of what else this could extend into.

Ultimately, the idea of having a similar dashboard experience from local to live may be a distraction. However, since we are exploring what this could look like beyond refreshing the existing appearance, now is the time.

I'll post feedback next, but I have several meetings the rest of today, so it might be tomorrow before I can list specifics.

[rickmanelius]

@andrew-c-tran Curious what your reaction is to @jdarrohn's mocks. I imagine this has been discussed offline with Jed directly, but I'm not privvy to those convos and it would be helpful to get your read as well (if it's not already in Slack).

[andrew-c-tran]

I do like the new comps, and I can see a huge benefit in using them on multiple sized devices. the card view flat out won't work in any sort of a graceful way on a mobile device, where the list view would pretty gracefully.

I know that's not a concern at this moment, but I could imagine using this as a hosted site solution as we've discussed in the long term roadmap and with a quick glance on mobile on status for several hosted projects would be amazing, and if we're going to swap interfaces it'd be better to do it now rather than introduce a radically different interface to existing users.

I feel like the local/live situation could be handled pretty easily by having duplicate views of the same list view a la slack and different orgs, and it might be more intuitive.

The biggest question that I have is due to lack of real world "time in the trenches." The current card view allows you to very quickly start/stop/delete/restart/view files/launch in browser in one click due to all the interface buttons being on the card on the dashboard. The drawback, however, is that the real estate that each card takes up means there will be less that can fit on a screen, and thus will require more scrolling.

The benefit of the list view is a clean and large list of things so we can quickly see many more projects and their current statuses at one time.

So, in summary, is it more important in real world usage to have these functions at a quick glance, but be limited to 6-8 projects on screen at a time, or is it more important to view many projects at a time and quickly see their statuses with having to select an individual one to launch actions be more beneficial?

[andrew-c-tran]

the more that i think about it, i am leaning more towards merging a sidebar concept into the current cards layout. Both kalabox and kitematic heavily rely on cards/tiles, and the sidebar would be a very handy place to display platform specific commands, as well as show the current selected platform. For example, the sidebar can have an icon for development, pantheon, DDEV Live, etc, and the context under it can change to commands specific for that platform. Changing the environment in the left toolbar will change the dashboard panel.

thoughts @rickmanelius and @jdarrohn ?

[rickmanelius]

Personally, I think this issue is now stale and replaced by the now-closed issue here https://github.com/drud/ddev-ui/issues/8.