Posted by drumm on November 4, 2007 at 7:16pm
I facilitated a session at the Bay Area Drupal Camp (BADCamp). About 40-50 people had a good discussion around the usability in Drupal.
I recommend the discussion format for similar sessions because the biggest need is getting people involved. There are success stories around specific UI redesigns, such as projects on Drupal.org and the administration front page introduced in Drupal 5. However, the overall usability process and vision is still taking shape.
My main points included:
- There are a lot of job titles, such as information architect and graphic designer, loosely grouped with usability. Everyone has skills to bring.
- Getting UI designs done is conversation and consensus building. UI designers and developers need to work together to get UIs done.
- Drupal has three big usability projects:
- Administration and other interfaces in Drupal core
- Tools for module developers and site builders
- Drupal.org
- Establishing guidelines and standards is important.
Please post your notes and thoughts in comments here.
Comments
heyho, here we go...
Good thing. Did you get them to sign up or leave their username/E-Mail-Adress? hehe
Life is a process
Life is a journey, not a destination
No, but I did strongly
No, but I did strongly encourage people to head over here if they were motivated to work on usability.
Sweet
As I like to tell sometimes, design is a dialogue.
We really need to finish setting up our mockup/prototype for node Edit pages, and show it to the real world for feedback.
audio/video or slides?
Sorry i missed it, did you guys manage to get audio/video or slides? I've got a bit of bandwidth, i'd be happy to assist where i can.
TravisC
Audio from the Usability Discussion
No slides, just a discussion.
But I did record & post it.
You can download it from here: http://blip.tv/file/get/Kentbye_tech-SFDrupalCampDiscussionAboutDrupalUs...
Or you can plug this RSS feed into iTunes to download all 12 sessions that I recorded: http://kentbyetech.blip.tv/rss
It was a great discussion.
Thanks
For posting the recording, that was indeed an interesting discussion!
I realize we've probably gone a bit too far with the node editing stuff. Initially we were looking for ways to "shorten"/reorganize the admin pages, as they can get really very long, and intimidating for end users too. Is it possible we've been a little bit too passionate? :)
The content edit screen is
The content edit screen is an incredibly hard problem. There are lots of disparate user goals and lots of possibilities for what elements might be on that page. The design goal is to make a system which encourages the various parts from core, CCK, and modules to come together in a coherent way. It should be good by default, and flexible enough for administrators to make it great with little technical effort.
I think it is a good long-term goal, but not something to be attempted all in one push. For example,
Cumulatively, the small changes will get to the content edit screen and make it better.
I think there is great
I think there is great opportunity to get involved as parts of CCK move towards core. Drupal 6 was about API simplification for CCK and I think more will continue to move towards core, including large parts of the field management UI.
design pattern: CSS grid
You could try a CSS grid if you wanted to give the form some columns.
Basically you specify a height and width for each form-item, then do a float:left; on each. The main-form-container will have to have a set width which is double or triple the size of the of the form-item depending on how many columns you require.
Problem is something like this would get tricky if it was totally dynamic. You would always have to assume that there was a set character number on the labels otherwise you would have to do a overflow:hidden; or truncate and that gets ugly pretty darn quick.
TravisC
Thanks
Thanks heaps for uploading the recordings Ken! :)
Bevan/
Visual elements
One thing that stuck out was when Neil said that there are only two admin UI tools that can be used: tables and fieldsets.
I asked what about images and icons?
And Neil said that there aren't good enough GPL icons, and that there are debates about whether they should be GPL or Creative Commons.
I wanted to pass along mortendk's icons that he made at Barcelona: http://morten.dk/blog/mortendk/icons-drupal-late-night-note-collection
Tao Starbow mentioned that there are others as well.
I made another point about scrolling -- whether to try and avoid it or not. Neil said that there seems to be a 50/50 split, and that he thought people should just learn to scroll.
I tend to think that if the same functionality can be accessible and it avoids scrolling, then the efficiently compressed version is probably going to be considered more usable by a wider range of users.
For an example of both images and compressed UI layout, here are some screenshots of the latest Joomla! 1.5 RC3 admin screens.
Screen resolution: 873 x 551
Screen resolution: 906 x 493
Notice the collapsible fieldsets where the block would be.
Also the header is compressed, and there are icons in the upper right
Screen resolution: 909 x 488
Also notice that I'm not telling you what this screen admin is: it is clearly written that this is the article manager, and the previous one was for creating a new article. There are also icons next to the "Article Manager."
Anyway, I think there are ways that to maximize the use of screen real estate with multi-column, making headers smaller, shifting blocks down -- or disabling them, moving admin drop-down menus up top and adding images for common functions.
Hello this is good
hey kentbye!
If you got time stop by Monday at 18.00 UTC on #drupal-themes.
We are discussing the same matters there every monday and you are very welcome. Also we are trying to produce mockups and a working html prototype (tweaking the drupal backend) as to bee seen in this thread: http://groups.drupal.org/node/6516#comment-20092
It started from a BoF on drupalcon barcelona and is generally about improving the ui, specialized at the moment at the content entry/edit forms.
Thomas
Life is a process
Life is a journey, not a destination
Vertical scrolling One
Vertical scrolling
One source saying vertical scrolling is okay is Jakob Neilson, "On the Web, users expect vertical scrolling. As with all standard design elements, it's better to meet user expectations than to deviate." (http://www.useit.com/alertbox/20050711.html). He also states, "Display all important information above the fold." I have read various other sources debating one screen vs. scrolling. One particular difficulty is knowing where exactly the page break is with different browsers, font sizes, screen sizes, window sizes, and Drupal themes.
I think the one-screen guideline might be useful for some pages, but should not be a hard rule. Above all else, a page needs to help the user's goals. This often means removing or hiding unimportant elements, the page becomes one screen tall as a side effect of other processes.
Icons
Like all new UI elements, icons require deliberate and well-reasoned introduction. For example, it took me awhile to figure out the blue splotch in views module administration meant delete. We certainly are under-using icons now, but I don't want to see us over-use them.
A good place to start might be the notices, warnings, and error boxes made via drupal_set_message() or form validation errors. Many themes use icons here already and they could use better visual treatment than a gray or red box.
There are potential legal woes which might be stirred up by adding icons. We have a lot of people who are not lawyers. The goal of the licenses we work with is sharing information, but they get confusing and prevent sharing. Do not let it stop you, just be aware that is a discussion that will probably happen.
Tables and fieldsets
These are the only well-developed tools we have for organizing the main content area in Drupal core. That is why we see too many of them. If we had more good tools in our toolkit, more would be possible with less code. Taking existing patterns, like filters on content and user listing admin pages, and desired patterns for implementing new UIs, standardizing them, and baking them into Drupal core improves what is possible and ensures consistency.
GPL Icons
Well, there are some to be found on the net. Apart from the Lullabot set:
http://www.iconfinder.net/
If you enter e.g. "delete" there are lots of lgpl Icons. I don't know: is lgpl enough for us?
http://www.iconlet.com/search?n=save another searching place
http://www.maxpower.ca/free-icons/2006/03/05/
This is a big list also including GPL
http://www.everaldo.com/crystal/
And what about crystal project
Life is a process
Life is a journey, not a destination
scrolling and icons
The one-screen guideline is terrific as a goal but should never be a hard-and-fast rule. Certainly you don't want to be part of that school of design that has a nicely designed page, and all the content in a tiny scrolling frame. in our opinion pages should be able to expand organically.
The rule shoudl be this: "if you can't fit your information into a single screen, then it should be simplified or divided".
On the icons front: they're terrifically useful -- but only if they have text equivalents. That require placing text next to icons or having tooltips appear on rollover. At that, you'd need users to expect the tooltips in the first place.
@modulist
Is all scrolling created equally?
It's worth considering the different experience of scrolling content and scrolling admin areas. The big difference being that content is generally read in a linear fashion from top to bottom. Admin screens, on the other hand, are usually not interacted with in that manner. If all you are doing is filling in your name, address, credit card info, etc, then you may not need to scroll back and forth so much. But many admin tasks are carried out in a random order. Things get amended. Settings are randomly changed. Sometimes different elements interact (like adding images to the body text, for example). Scrolling up and down takes up a lot of time. Though usually less time than a page reload.
I'm also not sure the expectation of scrolling on web pages automatically transfers to general web UI. If you think of a desktop application like a wordprocessor, for example, the main scrolling element is again the content. All the UI stuff stays consistantly available above the fold. Email application the same. Image manipulation the same. Spreadsheets the same. IRC, the same. Does the experience really automatically change because it is in a web browser? Google Reader and GMail are certainly two examples that take their inspiration from the desktop and work because of it.
-
www.alanpritt.com
Context
Regarding scrolling
Totally agree with alpritt. Scrolling on a page or blog post is okay, even a very long one, because you read it from top to bottom, and usually only once.
Going back and forth between admin pages can already be tedious, but when you need frequent access to a setting buried at the bottom of a 3 screens long page it simply becomes annoying.
Careful organization of admin pages can help, but ordering module's fieldsets on an edit page is not simple.
Regarding icons
Using a ready-made set of icons may not be the best option. We will miss some icons, it will be difficult to create new ones with the same style if we don't have the source files, and from a communication standpoint I wonder if we really want icons dozens of other projects already use. They'd be a part of Drupal's identity.
We can create our own icons. I may seem like a monstrous task, but the goal is not to iconify every button or link. We can start with a small set for a few key controls (like node edit buttons and $message texts), then slowly add new ones when really needed.
There is quite a lot of constraints if the goal is adding them to core tough. The task, object or verb they represent should be obvious, they should work with any theme, source files must be available and useful if people want to create new ones, and so on.
Regarding tables and fieldsets
We also have tabs.
My feeling is they are often misused. They're a mix of contextual panels, actions, settings, etc. Most of them should in fact be buttons IMO. Tabs are supposed to be "views" of things in the same context, so the tabs on the main admin page are correct: "By task" and "By module". On other screens we have "List" and "Add xxx", which is not that good, a view and an action. On blocks page we even have two rows of tabs, the second one being so long it displays on two lines (is there a good reason why we can see and change settings for inactive themes?), quite confusing.
A major difficulty is that Drupal has grown organically, step by step. It's difficult to break things apart because there was probably a good reason and a valid decision behind each detail, every button position, every fieldset layout, even if the overall result when all the parts are assembled sometimes feels wrong.
The original commit message
The original commit message for tabs states:
I faintly remember this might have been recommended by kika or Michael Angeles. I could not find anything other than the commit message. The original vision was tabs are local tasks, verbs. For example, create, view, list.
Making and using better guidelines is possible. Just have to agree on what to do, find someone to implement it, and get it in for Drupal 7.
The various UI difficulties caused by having the ability to run on different sections of the site or selected by users are a problem. The blocks page is an example of problems this causes.
Tabs, local tasks, navigation & actions
Tabs are called 'local tasks' in code, but are (mis-) themed as tabs. I think they relate directly to Joomla's buttons on the top-right of Joomla's admin interface.
Proposed guideline for these use-cases;
Whether 'local tasks' become tabs or buttons is another debate. But I think that 'local tasks' should be standardized as one or the other, and an additional UI component created for the other.
Bevan/
Well put. Also consider Collapsed fieldsets within blocks
So to re-summarize the potential Drupal UI toolkit: tables, fieldsets, tabs, icons, and I'd like to emphasize multiple-columns -- specifically collapsible fieldsets within blocks.
A good mutli-column example is to take a closer look at the Joomla! admin page for creating an article. They have a really slick set-up, which would be the equivalent of a series of collapsible fieldsets within the boundary of a single right-hand block.
Here's a screencap sequence of three screens showing what is looks like when the fieldsets are expanded. Try to imagine smooth javascript transitions between each segment, and click through for a closer look.
This is one area where Joomla! does a good job of maximizing the available real estate, while Drupal keeps the blocks the same on the admin side as the non-admin side.
Here is an example where you can compare Joomla & Drupal use of screen real estate (click through for a larger view):
IMHO, I think it's worth considering placing all of the Drupal fieldset links that aren't even showing up above the fold in collapsed fieldset block on the right like Joomla! does.
"Should it be considered to
"Should it be considered to either disable blocks on certain admin screens?"
I simply do this w/ the textarea on the block configuration page. It's obviously not really user friendly, but it's possible and helps a lot (esp. with administering orders in Ubercart).
(Ideally, since Drupal supports admin themes, I'd have a specially formed admin theme that actually makes administration easier. It could take care of some of these issues and use smaller/less spacey CSS rules to fit more on my 1024 x 768 screen. : )
New Default Admin Theme in D7?
Good point about the admin theme, perhaps Drupal 7 can come baked with a more robust core admin theme since all of the existing themes could all use some improvements.
Has this been already discussed as a possibility?
Strongly discussed
;) yep.
It has been thought to offer it as contrib for sure. Hopefully it will be such a roaring success, that 97% will use it in the end...
Nice Dropdown menus like in Admin_menu, but cross-browser compatible (well that's mainly my idea at the moment), working on getting every form short and sweet and work on guidelines for module developers to ensure consistent implementation for the future.
Might sound a bit ambitios but we can cut down anyway. Need a big vision to get the energy flowing...
Life is a process
Life is a journey, not a destination
Dialog Box & Tree Sorting Demo
That's great to hear.
Yes, I agree about being ambitious.
Tao Starbow was in the UI discussion, and alluded that he wanted to start pushing for using more jQueryUI for things like dialog boxes and drag-and-drop hierarchical menu tree sorting. Here's a very brief demo of his Quick Admin Menu module, which requires the jQueryUI Backport module (click on the picture below):
He warns that it is still a bit crufty and needs a bit more work.
Starbow is the wizard behind the AJAH forms module, which eventually got baked into Drupal 6 core. The drastic improvements of block sorting in Drupal 6 is thanks to a lot of his work. I think it'd be great to get more of
Thanks for the plug
I just released the beta2 of Quick Admin Menus on Monday. As Kent says, it now uses jQueryUI, relying on my jQueryUI Backport module to make it play nice with Drupal 5. I am changing the name from Quick Admin Menu to Quick Admin Menus to try and make it clear that it is a tool for editing menus, not another tool for viewing the administration menu.
Also, to keep the record straight, I do hope my AHAH forms module & presentation was part of the inspiration, but other folk did the hard work of actually getting AHAH functionality into Drupal 6.
Cross-browser Admin Menu Dropdown = Simplemenu
If you are looking for a cross-browser admin menu dropdown, have you checked out the simplemenu module? It is super easy to use, and I have used it with Firefox, IE6, IE7 and Safari.
Sure
I definitely want to work on this. First as a traditional "scratch your own itch" project, but I'll share my progress. Should we open a topic about what an "admin" theme has to offer? Probably in Theme development group?
Jeremy Caldwell also working on an admin theme
I just came across this post by Jeremy Caldwell where he says, "I also implemented it into a custom Drupal admin theme I am working on which I will release real soon. So check back for that one early next week." That was at the beginning of November, and there doesn't seem to be any update.
But it might be good to get in touch with him about this -- he's eternalistic on drupal.org
He helped theme the latest version of simplemenu, as Ted Serbinski points out in his simplemenu 4.0 release announcment.
If trying to move fieldsets
If trying to move fieldsets into blocks, it'd be well worth looking at Panels 2 and mini-panels - which already allow you to override the node/add form via contexts. I've not played around with that aspect of it, but there's a lot of potential there.
jQueryUI Accordion
People interested in collapsible fieldset effect should check out the jQueryUI Accordion. You can see a demo at:
http://dev.jquery.com/view/trunk/plugins/accordion/
Icons
I agree with Elv, we shouldn't poach icons from other sets, even if we're allowed to under their license. It does nothing for the branding of Drupal, and will likely end up looking mish-mashed.
I've been tinkering with a forum icon theme already, it uses 8bit PNG's with alpha transparency, so it degrades pretty gracefully for older browsers.
If we can out together a short list of icons, and start brain-storming on what symbols / images best represent them, that would be a good start.
It is possible to approximate above-the-fold page break
Re: Vertical scrolling
Drumm said, "One particular difficulty is knowing where exactly the page break is with different browsers, font sizes, screen sizes, window sizes, and Drupal themes."
Well, there is an easy way to approximate page breaks -- I'd imagine within a margin of error of 10% or so, which I think could be useful. The Firefox Web Developer Toolbar actually has an option to resize the browser window to a specific width & height. A specific width & height could be determined for recommending putting the most important items above the fold.
Here's how to set up custom screen resolution sizes:
* Firefox Web Developer Extension Toolbar -> Resize -> Edit Resize Dimensions...
* Add and save a custom 1064 x 768 size
* Add and save a custom 900 x 600 size
* Hit the upper righthand corner of Firefox to hide the Navigation toolbar, Bookmarks toolbar & Web Developer toolbar
* Firefox -> View -> Disable Status Bar
* Take a screenshot & post online.
NOTE: the height doesn't include the title bar, but the width does include the scrollbar.
Once Firefox's window size is set, then IE, Safari and other browsers could be resized and compared.
Then there could be a way to approximately determine where the page break occurs across browsers.
Font sizes and themes are wild cards, but even those could have a recommended sizes and dimensions.
Here is another sample of comparing the page break on a Firefox screen resolution of 1064 x 768 & 900 x 600:
Common Sense Design
So we all come to the same conclusions in the end: scrolling for UI Stuff is no good. Solutions vary, we already proposed one in putting all the options in content editing form in an extra "settings" tab.
Ximo has done a hackish but working prototype: http://kreativmango.no/dev/drupal/node-tabs/#
click on the "settings" tab to see.
I don't care about the method in the end, main thing is to present things more handy and easier to use.
@kentbye: We also had the comparison with Joomla and some more (including Wordpress) content editing forms:
http://groups.drupal.org/node/6516#comment-18934
But there is one big difference in Drupal: the content editing form is normally presented in the frontend theme. After rolling it back and forth we came to the conclusion is has to stay like this. (Details maybe next monday? Hope to see you all on IRC #drupal-themes at 18.00 UTC every Monday.
So you cannot use the entire screen for the form. It may even be that the content area is rather narrow, depending on the design. So in the end I gave up columns - just not enough space for that. This does not mean you cannot continue on the road and come to different conclusions.
Maybe there are more options...
Life is a process
Life is a journey, not a destination
admin theme
D6 has a new option:
[ ] Use administration theme for content editing.
(Use the administration theme when editing existing posts or creating new ones.)
Where can this be set? Is
Where can this be set? Is it set per-user, per-node-type, per-node, per-site, or something else?
Bevan/
/admin/settings/admin
It's per site.
And the path for that
And the path for that setting? I think it makes more sense to do this per role as a permission, and/or per user. But this is a step in the right direction to solving the user-flow vs too-many-node-settings-for-a-front-end-theme debate.
Bevan/
When did this happen?
When did this happen? Do you mean in this discussion, another related discussion, or an old discussion? Please provide a link.
Bevan/
Summing up my opinions
I wish I had read this thread earlier. I have been a bit out of touch for a few weeks now...
+1 for baking design patterns into drupal core. <a href/node/7294">7294 should support this.
+1 for separate default admin theme for drupal. Sooo many drupal sites already have a separate admin theme. Sometimes only to allow for separate block settings (the textarea on block configuration pages is cumbersome). Such a theme should incorporate an admin menu ala simplemenu, be full width, and try to get most of the most important settings above the fold. But,
-1 for putting /everything/ above the fold, however
+1 for better-utilizing screen-real-estate by
* having a better admin-optimized default admin theme (as above)
* implementing accordion (or similar) in a muli-column layout
It's worth discussing here the possibility of an inline-edit mode for light-weight editors -- something I blogged about a while ago. This makes sense for content editors that aren't admins and don't have permissions for any of the extras; http://drupal.geek.nz/2007/06/my-first-drupal-module-proposal.html
Bevan/