UI/Design Meeting Notes
charlequin
related to Mortar design tasks, as well as to perform a "dry run" with
the system in its current state in order to gather feedback on the
usability of the Mortar admin system in its current state. In the
process of this walkthrough, I gathered a number of suggested changes
to the Mortar interface, some major themes of which are summarized
here:
* There is a general lack of explanatory text throughout the
interface; many parts of the interface could become clearer and easier
to use by providing text that contextualizes the options and
* The universal-commands-on-left, contextual-commands-on-right
structure is unclear visually; moving universal commands to a top menu
and moving the contextual menu inside the bounds of the "admin content
box" (to more closely associate it with the content it's acting on)
ought to help with this.
* A way to move easily with a single click between the admin side and
user side of the site is desperately needed. (Joshua suggested moving
towards a model where the "admin side" is actually just a series of
extra menus bolted onto the user side as a long-term goal to maximize
the usability of the administrative interface.)
* Use a message system to constantly communicate information to the
user, wherever s/he is in the admin system. Some topics to raise:
message saying YOU ARE IN MAINTENANCE MODE (right now it's basically
impossible to tell when you're logged in if you are or not, except by
going to the Maintenance Mode action and checking), notes about out-of-
date components, telling you "you have logged in," etc.
* More cross-referenced information. For example, Group read pages
should list all the default (root-level) permissions for that group
and include a direct link to the action to set those root permissions.
User read pages should list what groups a user belongs to, what root
permissions those leave him/her with, and provide direct links to set
both the User and Group root permissions.
* Better menu sensitivity. Two examples. One, the Log In action has no
menus, which means if you go directly to the Log In link (rather than
being redirected there due to a permissions issue) it takes you to a
page with no menus after you log in, "stranding" you unless you click
through the breadcrumbs. Two, there are no context menus for any non-
Location models now, reducing usability; these menus should populate
in the same way that they do for Location models (listing default
actions plus any added by plugins.)
(Joshua also suggested some interesting ideas for the tagging system
which may be the start of a completely different conversation.)
On Mortar design issues specifically, we first discussed the status of
the Cloisonne theme which will be used both as the theme for the
builtwithmortar.org site and potentially as the new default theme in
each Mortar installation. Joshua said that the theme in its current
state "looked pretty good" but agreed to look it over and provide a
list of suggestions for small styling tweaks that would improve its
appearance.
Secondly, we discussed logo/branding issues. I discussed how our core
Mortar identity is rock-solid (the 3x3 grid brick logo, the dark-grey/
light-grey/red color scheme, the typography) and we now need to move
into executing branding for our submodules, at least some of which we
want to position as "full" products in their own right. I raised the
possibility of executing treatments for some of these products using a
different spot color (replacing the red) in order to help visually
distinguish them at a glance from the Mortar core and make styling
around each easier. I also discussed our interest in using icons to
represent both these modules and their content types within the
software -- moving away from the 3x3 grid for the actual content type
icons but hopefully maintaining an overall sense of consistent style
between our different modules.
During the course of this discussion it became clear that we do not
have a completely solid grasp of which direction precisely we should
take our branding for these modules in the future, and Joshua agreed
to put together some speculative design work on these matters with the
aim of exploring what direction to take them. I in turn agreed to
provide to him a list of the modules we are currently exploring along
with the content types they include, which I have included at the end
of this mail.
With this conversation complete, the next stage for Mortar in UI
design will be for me to incorporate the feedback received from this
experience in revamping the admin interface; the next stage for Mortar
in branding design will be to examine the results of Joshua's module-
branding exercise and work to determine and then establish our
specific module branding system through integration into the software
and our web presence on builtwithmortar.org.
List of sub modules, based on our current nomenclature, with content
types listed after:
CMS family:
* Litho (CMS module) -- CMS page
* Chalk (blog module) -- Blog/Blog Entry
* Graphite (wiki module) -- Wiki Page
Package-manager Family:
* Foundry (package client) -- package/module
* Quarry (package server) -- ditto
Others:
* Tessera (forum module) -- Forum/Thread/Post
* Unnamed-store-module -- Store/Category/Item
* Obelisk (?) (CRM module) -- Contact/Organization/Group