http://groups.drupal.org/usability Help make Drupal much more easy to use en http://groups.drupal.org/node/14561 <p>being unable to change the * easily for required fields makes your site 'look' like all the other drupal sites, and can pee you off if you don't want that! ie. if you want to change it to '(needed)', or whatever etc to suit your audience (older users of a site won't be trained to know what * means), so i think it should be translated to allow the drupal admin to get to it.</p> <p>ie. i love string overrides module as a quick way of changing a few strings, and hope that something similar will be built into the 7 . eg. changing the text that appears for the help of freetag vocabs should be <strong>easily</strong> changable. preventing this will only frustrate users, and will dictate to drupal admins, 'you must have your site THIS way, not the way YOU want'.</p> <p>anyway, i couldn't find anything other than removing it using css so i've created a feature request, not sure if it's a feature request or bug: <a href="http://drupal.org/node/303899" title="http://drupal.org/node/303899">http://drupal.org/node/303899</a></p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/14561#comments usability forms Usability Thu, 04 Sep 2008 12:28:36 +0000 George2_ 14561 at http://groups.drupal.org http://groups.drupal.org/node/14525 <p>in some places around drupal, ,the submit is on the left, and preview on the right, and are completely reversed in others. can this be standardised please.</p> <p>also, when the enter key is pressed, should the default action be to post, not preview. as enter is normally a substitute for pressing submit in most forms, why break it?</p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/14525#comments usability submit Usability Wed, 03 Sep 2008 12:44:24 +0000 George2_ 14525 at http://groups.drupal.org http://groups.drupal.org/node/14489 <p>Please give you feedback on this proposed change:</p> <p><a href="http://drupal.org/node/193799" title="http://drupal.org/node/193799">http://drupal.org/node/193799</a> =&gt; Warn before losing changes (e.g.: blocks and menu admin pages)</p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/14489#comments Usability Tue, 02 Sep 2008 15:14:06 +0000 pwolanin 14489 at http://groups.drupal.org http://groups.drupal.org/node/14480 <p>hi everyone, i wanted to post up some thoughts and ideas that i found confusing from when i first started with drupal. this is mostly based on 5 experiences. i know 6 has come a long way from 5, but i don't really have that much experience of 6 yet, so sorry if some of this doesn't apply. so, in no particular order</p> <p>what's the difference between site building and site config? i found it very confusing to be able to form some kind of differentiation in my mind. ok, so site building, you build stuff for the site, but site config? ahh, like site title, colours, layout right? as it turned out, the one true site config menu item (site information) was right at the bottom of the site cofig menu!</p> <p>You mean menu's aren't site config? themes aren't site configuration? (you don't really 'build' themes per se in the themes menu).</p> <p>i think to make drupal more accessible to the uber newbies, i'd like to see more promotion of install profiles, that way, ppl can dl a blog setup, a flickr copy setup, a forum setup etc, then blam! they've got it all up and running no questions asked - and they have the option to build, extend and develop with drupal as and when necessary. when the user-level people think cms, they prolly think wordpress, and expect to be able to install, then get it up and running, so this may make drupal accessable to a lot more individuals, and with the strong drupal background, perhaps blow wp out of the water?</p> <p>setting up themes is a nightmare in terms of having to click here, click there, navigate to this menu etc. ie. where do i enable the search block - in the theme or as a block? or the block isn't enabled, but i see a search box? i think hardcoding things like title, slogan, mission statement, search box into the templating system is sloppy, maybe this could be created by the user as cck fields?</p> <p>as a semi-experienced thought - and delghting in panels2, could there be a layout option where users can click on the list of page content, then edit the layout in a panels drag and drop manner? maybe this could be grouped by taxonomy (ie. design layout for a whole section). mhh maybe that's a whole separate module - just a thought.</p> <p>navigating aroudn the default admin menu is a nightmare, having to click to see the admin menu open up, then click to open up the site building menu, then click etc etc. yes i know about the admin menu module, and other dhtml menus, but why not have one as an optional module, or just one for the admin menu? jquery is packaged with drupal, so why not use it! so an core-optional module?</p> <p>i was blown away by the tens of extra divs that was put into my code, so, for a simple page, parts of it looked like hello world - reading it is a nightmare, feels excessive and messy.</p> <p>would it be possible to click on a node content type, then be able to directly edit the template in a window or such? i hate the templating system in vbulletin, it's confusing, and prefer to open up a text file personally, but i know people who are afraid to venture into the sub directories. this would then mask the node-NODETYPE.tpl.php requirement, and make it much more transparent.</p> <p>maybe there could be an "edit template" api exposed for modules? so views could have a "edit template" in the list of views, which would then create / edit a template for that view. personally myself, i prefer the option to open up the template files into an editor, but doing this would make it immediately more accessible, and with a line of "this template is called node-foo.tpl.php and can be foudn in sites/all/themes/..." would ease the user who's interested into manual editing.</p> <p>modules - ok, so adding modules is great. however, do i use this module or that module? that both seem to do the same thing, so which is better? as a complete newbie, how the hell are they to know? also, when you add a module, what happens? is a new menu created, is a new option somewhere added - not all modules have great documentation. so, i'd like to suggest that in the info file, an extra line, or description is added to state "this module adds a menu in the site config menu called foo, and also allows the option of moo and poo". this would save the confusing option of remembering for a newbie what menu option is in site building or config, and then having to hunt it down.</p> <p>i'd like to also suggest that there's a template standard documentation file for modules. with such tight coding standards, i'm surprised this hasn't been done!</p> <p>also with modules, the perms that they expose, some are implicit and automatically granted, whilst others have to be manually granted to the role type. so, newbie heads on over to user permissions, and ticks 'access foo', for the unauthenticiated users, only to unknowingly grant the logged out users permissions to see extra parts of the module they shouldn't because the module quietly granted that user group the necessary permissions - i'm sorry this bit has to be a bit of fluff as i';ve lost my notes and can't think of an example right now.</p> <p>also, with the access control list, when i'm half way down teh list, and i have 6 role groups i've set up, how am i supposed to know which tick bnox is for which? oh, i have to scroll all the way back up, then find the col, then back down again. so, like phpmyadmin does, can the groups names be repeated every x rows please.</p> <p>searching for aliases - when you have a few, clicking the pager isn't fun, so a search box on there is necessary.</p> <p>save / cancel / save and edit. the latter is essential for dev work and makes the life expectancy of the back button much longer (it's used less you see!). so, panels, views, heck, and even node creation would benefit from one - who wants to type up a long 600 word rant, only to find a powercut wipes it all out? you hit ctrl+s often when you're working with files, so this is only the much-needed equivalent</p> <p>ok, this is all i can think of for now. hope it's not useless banter, and some positive discussion can be had from it!</p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/14480#comments usability first-time Usability Tue, 02 Sep 2008 11:45:35 +0000 George2_ 14480 at http://groups.drupal.org http://groups.drupal.org/node/14428 <p>bertboerland, ximo, al.ex, Jan K, and I tackled the node form. We have results from <a href="http://groups.drupal.org/files/UMN-preliminary-usability-results.ods">Minneapolis usability study</a> for Drupal 6 and <a href="http://groups.drupal.org/files/DrupalUsabilityResearchReport.pdf">Baltimore study</a> for vertical tabs.</p> <h3>Problems</h3> <ul> <li>Too long and unwieldy.</li> <li>Important information and controls are hidden behind fieldsets.</li> <li>Drafts are lost when clicking links, even help links.</li> <li>It is not obvious that permissions control what the content creator sees.</li> </ul> <h3>Discussion</h3> <p>We discussed improve the <em>admin's ability to design the form</em> and improve Drupal's use of <em>progressive disclosure</em>. Ideas included:</p> <ul> <li>Provide option to hide fields next to required checkbox on fields admin screen.</li> <li>Decide which fields to hide using usage statistics.</li> <li>Make a 1 to n priority system so content creators can choose their level of fields to show.</li> <li>Allow content creators to access hidden fields when needed.</li> </ul> <p>We also discussed improving Drupal's <em>split summary at cursor</em> feature.</p> <ul> <li>Find the best words and be consistent- summary, teaser, excerpt, read more, etc.</li> <li>Integrate with wysiwyg editors.</li> <li>Look at how Joomla, Wordpress and others handle this common interface.</li> </ul> <p>Finally, we discussed <em>vertical tabs</em>. We saw in Baltimore that these are a potential improvement, but not there yet.</p> <ul> <li>Summaries have recently been added under tab titles, they should be user tested.</li> <li>What is a good semantic term to use in code?</li> <li>UI standards are needed.</li> </ul> <h3>Action items</h3> <ul> <li>bertboerland and ximo will write standards for and continue to improve <em>vertical tabs</em>.</li> <li>ximo, Jan K, and I will think about and mock up new <em>split summary at cursor</em>.</li> <li>Jan K will mock up layouts for <em>multiple taxonomies</em>, which quickly use a lot of vertical space.</li> <li>al.ex will suggest <em>wording changes</em>.</li> </ul> <h3>Roundup meeting slides</h3> <p><img src="http://groups.drupal.org/files/edit-content-1.png" /></p> <h3>Notes after our roundup meeting</h3> <ul> <li>The "prioritysystem" for the fields and fieldsets adds another big layer of complexity</li> <li>So only the predefined contenttypes will benefit from our suggestions<br /> we're shifting the problem from one side to another</li> <li>We need to make suggestions for the contenttype creation form also since that is were we are shifting the burden to</li> </ul> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/14428#comments usability Usability Sun, 31 Aug 2008 14:13:27 +0000 drumm@drupal.org 14428 at http://groups.drupal.org http://groups.drupal.org/node/14427 <p>One of the Szeged UX sprint task were improve the contents and layout of this group. With great help from Drumm and Moshe we managed to base our layout on panels (e.g. superb flexibility) and we are now free to come up with any type of flexible layout for our home.</p> <p>We are just starting and there are a lot of room for improvements. Please give feedback if this new layout breaks on your browser -- block droppage has been reported -- and what else should be done. Webchick dropped an idea what they are using over <a href="http://groups.drupal.org/soc-2008">SoC</a>: have a special "featured" or "important" tag on content so we could list/sticky important discussions / going-ons automatically.</p> <p>Also there are some confusion over content types we are using in this group: "Jobs" have not used once -- should we kill it? -- there are some confusion whenever one should create a wiki or discussion on particular issue, this needs clarification.</p> <p>In related note, Moshe enabled attachments on comments so we can start having a "Photoshop ping-pong" exchanging ideas visually, at least in theory. Does it make wiki pages obsolete? Discuss!</p> <p>Also, Niels is working on new and improved "quicklinks" panel what you can see in the right. We are about to get rid of outdated and depreciated links there and have logical chunks for the information. It's a wiki page so everybody is welcome to improve and update it later on.</p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/14427#comments usability Usability Sun, 31 Aug 2008 13:42:07 +0000 kika@drupal.org 14427 at http://groups.drupal.org http://groups.drupal.org/node/14426 <p>kika made a diagram of the current information and information streams we have on usability, which were quite fragmented. I mindmapped a new way to divide that information so we'd have places for:</p> <p><em>People who want to help Drupal Usability</em><br /> <em>One place for discussions</em><br /> <em>One place for issues</em></p> <p>Here's the mindmap:<br /> <img src="http://groups.drupal.org/files/Drupal_UX_new_sm_0.png"><br /> (bigger version attached)</p> <p>Any comments?<br /> I've also attached the .mm Mindmap file which you can view and edit with <a href="http://freemind.sourceforge.net">Freemind</a> (open source &amp; cross platform). As D.O. does not accept .mm files, rename the file to end in " .mm".</p> <p>Next actions:<br /> *rearranging and updating the handbook <strong>big one</strong><br /> *cleaning up the forum<br /> *perhaps move some forum discussions to GDO</p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/14426#comments usability design ux user experience Usability Sun, 31 Aug 2008 13:18:44 +0000 nielsbom 14426 at http://groups.drupal.org http://groups.drupal.org/node/14423 <p>This group made the biggest progress and the patch is already in progress. Here are whiteboard grabs from the review meeting, courtesy of <a href="http://groups.drupal.org/user/11366">heather</a>.</p> <p><img src="http://groups.drupal.org/files/my-content-list.png" /></p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/14423#comments usability Usability Sun, 31 Aug 2008 12:38:06 +0000 kika@drupal.org 14423 at http://groups.drupal.org http://groups.drupal.org/node/14422 <p>The following people will set up this guide: Sutharsan, Gaele, Yngve<br /> Tasks:<br /> - Collect existing best practices (d.o, presentations, the web)<br /> - Compose preliminary guide in this wiki<br /> - Create guide as handbook page</p> <h3>In d.o / g.d.o.</h3> <p>Drupal Usability aims: <a href="http://drupal.org/usability-aims" title="http://drupal.org/usability-aims">http://drupal.org/usability-aims</a><br /> Season of Usability goals discussion: <a href="http://groups.drupal.org/node/7965" title="http://groups.drupal.org/node/7965">http://groups.drupal.org/node/7965</a><br /> Usability guide for drupal developers: <a href="http://groups.drupal.org/node/7294" title="http://groups.drupal.org/node/7294">http://groups.drupal.org/node/7294</a><br /> Usability Notes: Lists UI decisions: <a href="http://drupal.org/node/21754" title="http://drupal.org/node/21754">http://drupal.org/node/21754</a><br /> Handbook style guide: <a href="http://drupal.org/about/authoring" title="http://drupal.org/about/authoring">http://drupal.org/about/authoring</a></p> <h3>On the web</h3> <ul> <li><a href="http://www.welie.com/patterns/">Welie Design Patterns</a></li> <li><a href="http://developer.yahoo.com/ypatterns/">Yahoo Design Patterns</a></li> <li><a href="http://harbinger.sims.berkeley.edu/ui_designpatterns/webpatterns2/webpatterns/home">Berkeley Design Patterns</a></li> <li><a href="http://bugs.sakaiproject.org/confluence/display/DESPAT/Library">Sakai Design Patterns Library</a></li> <li><a href="http://www.cs.helsinki.fi/u/salaakso/patterns/index.html">User Interface Design Patterns</a></li> <li><a href="http://ui-patterns.com">UI-Patterns.com</a></li> <li><a href="http://www.oracle.com/technology/tech/blaf/">Oracle Browser Look and Feel Resources</a></li> <li><a href="http://www.designpattern.lu.unisi.ch/HypermediaHomePage.htm">Hypermedia Design Patterns Repository</a></li> <li><a href="http://www.cmis.brighton.ac.uk/research/patterns/home.html">The Brighton Usability Pattern Collection</a></li> <li><a href="http://fluidproject.org/">The fluid project</a></li> <li><a href="http://www.usability.gov/">Well prepaired guide to usablity by the U.S. government</a></li> </ul> <h3>Writing documentation</h3> <ul> <li>Create a README.txt template: <a href="http://groups.drupal.org/node/14523" title="http://groups.drupal.org/node/14523">http://groups.drupal.org/node/14523</a></li> </ul> <div class="og_rss_groups"><a href="/usability">Usability</a></div> Usability Sun, 31 Aug 2008 12:19:15 +0000 sutharsan@drupal.org 14422 at http://groups.drupal.org http://groups.drupal.org/node/14420 <p>We have <strike>15+</strike> 5+ people working on UX improvements in Szeged under the umbrella of Code Sprint. Below are tasks we came up with and synced with Webchick.</p> <p><img src="http://groups.drupal.org/files/drupalconszeged_uxsprint_tasks.jpg" title=""></p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/14420#comments Usability Sun, 31 Aug 2008 10:18:53 +0000 kika@drupal.org 14420 at http://groups.drupal.org http://groups.drupal.org/node/14393 <p>In Szeged Usability Sprint I started an initiative to collect best practices from the other CMSes. As videos are quickest and most effective way to give overview of the flows and functionality, I picked to use screencasts for that.</p> <p><strong>Habari:</strong><br /> <a href="http://habariproject.org/" title="http://habariproject.org/">http://habariproject.org/</a><br /> Screencast of the installation and site setup: <a href="http://kika.trip.ee/sites/kika.trip.ee/files/habari_screencast.mov">MOV</a> (20 mb)</p> <p>Add more to the comments and lets take it from there.</p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/14393#comments Usability Sat, 30 Aug 2008 13:15:28 +0000 kika@drupal.org 14393 at http://groups.drupal.org http://groups.drupal.org/node/14387 <p>Here is the visual discussion sketch of possible contents and related problems / dependencies of the first-time user help page. We kind-of nailed the contents of the help but it's interaction model, placement and relation with admin, post-install flow etc is still under heavy discussion.</p> <h3>Content</h3> <h4>Problems with existing content</h4> <ul> <li>Confusing task structure and order. Should it be ordered or unordered?</li> <li>No intelligence</li> <li>No internal / external links separation</li> <li>No sorting by importance </li> <li>Is the amount of content optimal? </li> </ul> <h4>Proposed content structure</h4> <ul> <li><strong>Primary</strong>: Create content</li> <li><strong>Secondary</strong>, internal: /modules, /themes, (site config, add accounts...)</li> <li><strong>Secondary</strong>, external: D.O. links, "embassy of D.O in you site"</li> </ul> <h3>Dependencies</h3> <ul> <li>Create content page</li> <li>Advanced help in core</li> <li>Installation profiles</li> <li>Prefilled content</li> <li>/admin</li> </ul> <p><img src="http://groups.drupal.org/files/uxsprint_disappearhelp_sketch_1.jpg" title="" /></p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/14387#comments usability Usability Sat, 30 Aug 2008 06:58:55 +0000 kika@drupal.org 14387 at http://groups.drupal.org http://groups.drupal.org/node/14312 <p>These are the groups we formed.</p> <ol> <li>help</li> <p>sutharsan, gaele, noyz, elv, kika, nestor</p> <li>lost content</li> <p>catch, eigentor, kika, JBI</p> <li>parent items</li> <p>roel G, Natbof?, AlexUA, imre (Byelex), kulcsi<br /> (__This group dispanded shortly after because of language / communication barriers. No parent items UX this time__)</p> <li>long form</li> <p>Dries, Alex, Jan, ximo, drumm </ol> <div class="og_rss_groups"><a href="/usability">Usability</a></div> Usability Wed, 27 Aug 2008 15:15:39 +0000 gaele 14312 at http://groups.drupal.org http://groups.drupal.org/node/14104 <p>We set dates and an agenda for the three days of UX sprint: <a href="http://groups.drupal.org/szeged-uxsprint" title="http://groups.drupal.org/szeged-uxsprint">http://groups.drupal.org/szeged-uxsprint</a><br /> Just want to keep everyone posted so you can plan your Drupalcon Sessions...<br /> First day is not completely safe as it depends on Jeff Noyes and Dries, but the rest should be O.K.</p> <p>If the Schedule does not appear right to you, please comment.</p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/14104#comments Usability Tue, 19 Aug 2008 21:38:17 +0000 eigentor 14104 at http://groups.drupal.org http://groups.drupal.org/node/14088 <p>(or how to reduce a module's functionality)</p> <p>During it's lifetime a contributed module's functionality expands, which often leads to a module packed with features. This growth of features is common for all software, but for Open Source the rate of expansion seems even higher. Feature rich software may be beneficial to the user but it comes at a price. Usability often suffers.</p> <p>To prevent <a href="http://drupal.org/project/simplenews">Simplenews</a> (of which I am the maintainer) from being cluttered with features which are not used anymore, I decided to make a <a href="http://simplenews.erikstielstra.nl">questionnaire</a> to investigate the use of the module. The purpose is to know how users use the module (how many newsletters, how many subscribers, etc.) which features are used and which new features are desired (from issue queue feature requests). With the results I hope to be able to remove unused features or move the less common ones into a 'dusty coner' of advanced settings or into a separate extension module.</p> <p>If you are a Simplenews user, please help by filling out the <a href="http://simplenews.erikstielstra.nl">questionnaire</a>.</p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/14088#comments contrib usability user questionnaire Usability Tue, 19 Aug 2008 07:27:12 +0000 sutharsan@drupal.org 14088 at http://groups.drupal.org http://groups.drupal.org/node/14036 <p>Hi, I posted a lengthy rant on Drupal UI challenges -- sort of an introduction to my thinking and experiences tracking Drupal UI story so far.</p> <p><a href="http://kika.trip.ee/node/364" title="http://kika.trip.ee/node/364">http://kika.trip.ee/node/364</a></p> <p>Discussion is welcome both here in this thread or over in my site.</p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/14036#comments usability Usability Sat, 16 Aug 2008 11:38:33 +0000 kika@drupal.org 14036 at http://groups.drupal.org http://groups.drupal.org/node/14030 <p>Forget about the user. There is no average user. "The User" <a href="http://acquia.com/blog/pretending-be-user#comment-736">does not exist</a>. There are different users, with different goals, different backgrounds and different levels of experience.</p> <p>And forget about usability. From Matthew Paul Thomas' <a href="http://mpt.net.nz/archive/2008/08/11/usability">blog</a>:</p> <blockquote><p> What do you mean by “usability”?</p> <p>Every so often, in a software project’s mailing list, bug tracker, or wiki, I see someone suggest a change they claim will “improve usability”. This is an unhelpful choice of words.</p> <p>It’s unhelpful because usability has multiple components:</p> <ul> <li><em>Learnability</em> — how easily a beginner can use the system, and how easily they can become an expert.</li> <li><em>Efficiency</em> — how quickly people can achieve what they want.</li> <li><em>Memorability</em> — how easily people can remember how to use the system or feature, after not using it for a while.</li> <li><em>Safety</em> — how rarely people experience errors, and how easy it is to fix any errors.</li> <li><em>Satisfaction</em> — how pleased people are with the overall experience.</li> </ul> <p>Sometimes a design change may be entirely beneficial. Other times, the change improves one or more of these usability components at the expense of others. </p></blockquote> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/14030#comments Usability Fri, 15 Aug 2008 23:34:26 +0000 gaele 14030 at http://groups.drupal.org http://groups.drupal.org/node/13988 <p>I've created a screencast comparing the user experience for entering data via Markdown vs. TinyMCE WYSIWYG:</p> <p><a href="http://blip.tv/file/1170327" title="link to screencast comparing WYSIWYG to an html helper ap">WYSIWYG vs. HTML Helper Screen Cast at Blip.tv</a></p> <p>There is a prevalent assumption that WYSIWYG's are easier for end users. I argue the opposite in the screencast. I made it to help shops convince their clients that an HTML helper is the way to go. Seems like most shops just assume they have to give their clients a WYSIWYG. We know all the reasons developers don't like these tools. The screencast I did is making the argument on usability grounds.</p> <p>WYSIWYG interfaces:</p> <ol> <li>Offer too many choices</li> <li>Present frustrating roadblocks (e.g. grayed out icons)</li> <li>Are not truly WYSIWYG (e.g. hyperlinks look like hyper links but aren't actually "hot")</li> </ol> <p>Please add to this list. Or comment on the issue of the usability of WYSIWYGs.</p> <p>A related issue is: why do clients think that they MUST have a WYSIWYG and why aren't developers making more efforts to convince clients otherwise?</p> <p>I started a <a href="http://lists.drupal.org/pipermail/consulting/2008-August/002500.html" title="link to the archive of discussion on wysiwyg usability">similar conversation</a> which has gotten a bunch of responses on the <a href="http://lists.drupal.org/mailman/listinfo/consulting" title="link to the home page of Drupal&#039;s consultants list serve">consulting list serve</a>.</p> <p>Shai</p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/13988#comments html usability WYSIWYG Usability Thu, 14 Aug 2008 20:21:43 +0000 Shai 13988 at http://groups.drupal.org http://groups.drupal.org/szeged-uxsprint <p>This is the tweaked summary of <a href="http://groups.drupal.org/node/13809/attendees">this IRC chat</a>. </p> <h3>We will focus on improving usability for new users.</h3> </p> <p>There will be a usability BoF every day of the conference.</p> <h3>Schedule:</h3> <p><strong>UX Sprint Day 1: Introduction and clearing of main issues </strong><br /> (see List below), probably together with Dries and Jeff Noyes<br /> <strong>Wednesday, Aug 27, 4pm Cisco BoF room</strong><br /> (maybe everyone pick a task on end of Day 1)</p> <p><strong>UX Sprint Day 2: Forming of workgroups, working on tasks and discussion in small groups...</strong><br /> <strong>Thursday, Aug 28, 4pm Cisco BoF room</strong></p> <p><strong>UX Sprint Day 3: Roundup, presentation of results, battle plans</strong><br /> <strong>Saturday, Aug 30, 1.30pm Sun BoF room</strong><br /> For presentations there is a Projector, as on the other days. Maybe our battle plans<br /> include to meet up in Holland later in the year for another UX sprint?</p> <p>From the list of issues as found in the two formal usability test we picked 4 topics that we want to work on:</p> <h3>1. Night of the Disappearing Help Page:</h3> </p> <p>People lose the welcome/getting started page after creating a first post, desperately want it back.<br /> - Make it stay/findable in some way<br /> - Fix the clashing terminology on this page.</p> <h3>2. Where Did My Content Go?</h3> <p>Trouble locating content after creating it/can't listing it at all if user does not have the 'administer nodes' permission.<br /> - Work on solving the technical issue?<br /> - Minimal steps to solve this?<br /> - Dive into the dashboard discussion for Drupal administration, admin theme confusion…<br /> - "Where is my site?" - Separation between Admin and Frontend/site concepts (create a dedicated Admin Theme)</p> <h3>3. How to create structures for my content?</h3> <p>People have a hard time building out their site structure: menus, taxonomy, outline?, book?<br /> - Catch and pwolanim are hosting a technical BoF on this as well.<br /> - hierachical select module and other form widgets we might need.<br /> - Create a default "getting started" content-structure for the default install profile?<br /> - Make menu structure more intuitive<br /> ... August, 30th Result &gt; Pitty that the 3 persons showing up at the second meeting, to start working on this had to conclude that their knowledge and experiences were incompatible. We concluded with us 3 that there was no ground for working further on this subject. A good conclusion in itself, still a pity, best regards Roel G. ...</p> <h3>4: The node/add form: Whoa!</h3> <p>Too much info at once, give users what they need up front<br /> - Too much scrolling, task links are above the help text<br /> - So yeah, how to get rid of those collapsible fieldsets again (is node form layouts the solution <a href="http://drupalmodules.com/module/node-form-layouts" title="http://drupalmodules.com/module/node-form-layouts">http://drupalmodules.com/module/node-form-layouts</a>) ?</p> <h4>todo:</h4> <p>Group issues into the 4 topics above, add links: <a href="http://drupal.org/project/issues?projects=3060&amp;components=usability&amp;states=1,16,8,13,14,15,2,4&amp;priorities=&amp;categories=&amp;users=" title="http://drupal.org/project/issues?projects=3060&amp;components=usability&amp;states=1,16,8,13,14,15,2,4&amp;priorities=&amp;categories=&amp;users=">http://drupal.org/project/issues?projects=3060&amp;components=usability&amp;stat...</a><br /> Battleplans for the HOW to do this. I hope we can get small teams working on each subject and iterate daily. We should not expect to work equally hard on each topic, we'll see what happens :-)</p> <p>Let's keep this page as focussed on the above as possible and continue the discussion over here: <a href="http://groups.drupal.org/node/12972" title="http://groups.drupal.org/node/12972">http://groups.drupal.org/node/12972</a></p> <div class="og_rss_groups"><a href="/designers-and-information-architects">Designers and Information Architects</a></div> Usability Designers and Information Architects Wed, 13 Aug 2008 09:47:55 +0000 yoroy 13941 at http://groups.drupal.org http://groups.drupal.org/node/13937 <p>If there can be any doubt, what users miss in core Drupal, have a look at this<br /> <a href="http://drupalmodules.com/top-downloads" title="http://drupalmodules.com/top-downloads">http://drupalmodules.com/top-downloads</a></p> <p>As the numbers of downloads rise beyond 3000, these relations start to get representative, or at least more so.</p> <p>Just have a look at Dries "Wishlist" for Drupal (gosh, cannot find the survey results anymore! But i know a Wysiwyg Editor in Core was very close to the top, together with better image handling) and wishlist for Drupal.org <a href="http://buytaert.net/drupal-org-wishlist" title="http://buytaert.net/drupal-org-wishlist">http://buytaert.net/drupal-org-wishlist</a>, at most prominent usability issues found at Minnesota and Baltimore and, er, some logical pattern shines through...</p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/13937#comments Usability Wed, 13 Aug 2008 04:14:26 +0000 eigentor 13937 at http://groups.drupal.org http://groups.drupal.org/node/13871 <p>How about thinking about this.<br /> Garland has had its time, and it starts to really hurt my eye.<br /> Sure going for a recolorable theme is a given necessity.</p> <p>I opt for Pixture, as I see it is very popular, and also because it looks "Joomly" (this may be a reason for people to NOT use it, I know ;) )<br /> In is actual edition it has layout tables, but I'm working on this flaw with someone. Sure I'm not totally out of hunger for personal fame, but more importantly this would get away from the "Drupal looks like Garland" opinion.</p> <p>Maybe this is already discussed and I'm only missing it?</p> <p>Maybe collect candidates?</p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/13871#comments Theme development Usability Sun, 10 Aug 2008 16:32:45 +0000 eigentor 13871 at http://groups.drupal.org http://groups.drupal.org/node/13809 <p>So we want to work on Drupal usability during Drupalcon. I proposed to have 3 BoF sessions during the first 3 days of the conference:<br /> <a href="http://groups.drupal.org/node/12972" title="http://groups.drupal.org/node/12972">http://groups.drupal.org/node/12972</a></p> <p>Let's have a chat in IRC and come up with an agenda and try to focus on the important issues that we could really work on in Szeged.</p> <p>We will meet in the #drupalcon channel</p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/13809#comments Designers and Information Architects Usability Thu, 07 Aug 2008 20:12:43 +0000 yoroy 13809 at http://groups.drupal.org http://groups.drupal.org/node/13738 <p>Hello,</p> <p>I am a Summer of Code student working on a project called Embed Widgets (<a href="http://drupal.org/project/embed_widgets" title="http://drupal.org/project/embed_widgets">http://drupal.org/project/embed_widgets</a>). It allows widgets to be created from Drupal content such as nodes, blocks, or views. Content must first be added as a "widget source" before it can be embedded in a widget. Widgets can be embedded in various formats such as IFrames and Google Gadgets, with more to come.</p> <p>My project is going great and is nearly complete, but one concern I have is the user interface. I am looking for ways to improve it.</p> <p>I have implemented the following features while editing a widget:<br /> -Dynamic user interface using AHAH.<br /> -Live preview of changes made to widget.<br /> -Draggable table to re-order widget tabs.<br /> -Views arguments can be input through UI. Some use autocomplete.</p> <p>I welcome any suggestions or critiques of the current interface.</p> <p>You may login to the demo site to test my project: <a href="http://deviable.com/widgets/" title="http://deviable.com/widgets/">http://deviable.com/widgets/</a></p> <p>I am also planning to implement an interface where end-users (non-admins) can create their own widgets. Not as many settings will be available, so this interface will be more simple. If anyone has any suggestions for that interface, please let me know!</p> <p>Thanks for your help!</p> <p>John Snow</p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/13738#comments Embed Widgets help review usability Usability Tue, 05 Aug 2008 18:30:07 +0000 jtsnow 13738 at http://groups.drupal.org http://groups.drupal.org/node/13634 <p>Just found this app. Thought I would share it. Havent tried it yet (not a mac user).</p> <p>Spontaneous, unobtrusive usability testing software for designers and developers.</p> <pre><code>* Capture screen activity * Video the participant’s reactions * Record the participant’s voice * Add chapter markers on the fly * Control recording with the remote * Export to Quicktime </code></pre><p><a href="http://www.silverbackapp.com/" title="http://www.silverbackapp.com/">http://www.silverbackapp.com/</a></p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/13634#comments Usability Fri, 01 Aug 2008 08:21:31 +0000 sign 13634 at http://groups.drupal.org http://groups.drupal.org/node/13355 <p>I think it's time taxonomy module got some more love in core. Drag and drop etc. was nice to get in D6, but there's much more we could do. Also I keep seeing various taxonomy administration helper modules cropping up - which is good, but there's no core patches cropping up alongside them, which is a shame, so I'm starting this in the hope of generating some discussion about things we could do this release cycle.</p> <p>There's three obvious areas where Taxonomy could use some help.</p> <p>Administration:</p> <p>Merging terms.<br /> Moving terms between vocabularies.<br /> Mass operations (delete, edit).<br /> Editing individual terms quickly<br /> Administration of large vocabularies<br /> Mass addition of terms (the quickest way to add them at the moment is free tagging at node/add)<br /> Cleaning up old crappy terms and preventing creation of new ones.</p> <p>There are modules which deal with some or all of these, but some of them have serious UI issues (i.e. taxonomy_switch) and it's often necessary to install 4-5 different modules on one site if you need people without db access to manage large numbers of terms.</p> <p>User interface:</p> <p>Apart from administration, the biggest problem IMO is mile long select lists:</p> <p><a href="http://drupal.org/project/hierarchical_select" title="http://drupal.org/project/hierarchical_select">http://drupal.org/project/hierarchical_select</a><br /> <a href="http://szeged2008.drupalcon.org/program/sessions/usability-enhancements-drupal-hierarchies-menu-links-and-taxonomy" title="http://szeged2008.drupalcon.org/program/sessions/usability-enhancements-drupal-hierarchies-menu-links-and-taxonomy">http://szeged2008.drupalcon.org/program/sessions/usability-enhancements-...</a></p> <p>API:<br /> Atttaching taxonomy terms to stuff other than nodes (fields in core)<br /> Maybe try to get term_parents reworked to use the menu system, and move multiple parents to contrib (if this is even possible).</p> <p>I reckon the quick wins would be:</p> <p><a href="http://drupal.org/project/edit_term">term_edit</a> and hierarchical select into core for D7.</p> <p>Maybe adding a 'vocabulary' field to the term edit screen.</p> <p>For mass administration I'm sure loads could be done with Views 2 but I've not looked into the possibilities in any depth.</p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/13355#comments Improvements to core Taxonomy Usability Tue, 22 Jul 2008 11:03:17 +0000 catch 13355 at http://groups.drupal.org http://groups.drupal.org/node/13114 <p>The Drupalcon Track <a href="http://szeged2008.drupalcon.org/program/tracks/showcases-ux-design" target="_blank">"Showcases, User Experience and Design"</a> is still taking Session proposals.</p> <p>It would be great to have more Presentations on UX Matters. Drupalcon is a wonderful Opportunity to contibute to the topic and maybe get more People on it, as targeted in the proposed <a href="http://groups.drupal.org/node/12972">Usability Sprint</a><br /> Anything that touches the Topic UX is welcome. Following the discussions here there is no shortage.</p> <p>To give you Ideas, the Presentations could touch the following topics:</p> <ul> <li> Principles of UX </li> <li> User Testing in Drupal </li> <li> Help System and Documentation </li> <li> Building a library of reusable UI Patterns </li> <li> Enhancing collaboration on UX improvement in the community </li> </ul> <p><strong>Principles of UX</strong> could touch Topics like the needs of the user, and why to structure information in different Levels, like depicted by Jesse James Garrett: <a href="http://www.jjg.net/elements/pdf/elements.pdf" title="http://www.jjg.net/elements/pdf/elements.pdf">http://www.jjg.net/elements/pdf/elements.pdf</a> .<br /> <strong>User Testing in Drupal</strong> should be just as important as Code Testing, and this might contain the <a href="http://groups.drupal.org/node/11011">Usability Testing Suite</a> that boombatower ist working on.</p> <p>Maybe you have written a module that enhances Usability? You have Ideas how to improve Drupals UX and ideas for a strategy to improve it? Step up and propose your Presentation. If your Presentation touches Showcases or Design, you are also welcome. For Details you can contact me (<a href="http://groups.drupal.org/user/3833">eigentor</a>) or <a href="http://groups.drupal.org/user/866"> yoroy</a>, or directly submit your session on the <a href="http://szeged2008.drupalcon.org/program/sessions">Drupalcon Site</a>. Proposals are accepted until July 27.</p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/13114#comments usability drupalcon ui ux Usability Sat, 12 Jul 2008 10:43:34 +0000 eigentor 13114 at http://groups.drupal.org http://groups.drupal.org/node/12972 <p>Improving usability is a top priority for Drupal 7: <a href="http://buytaert.net/usability-usability-and-usability" title="http://buytaert.net/usability-usability-and-usability">http://buytaert.net/usability-usability-and-usability</a></p> <p>So, it is also a big topic for Drupalcon in Szeged. Besides presentations and sessions we should work out a format for actually getting some stuff done, too. Let's call it a Usability Sprint. We should focus on fixing the actual issues found by the two <a href="http://groups.drupal.org/node/12447">usability</a> <a href="http://drupal.org/usability-test-university-baltimore-community-solutions">tests</a>.</p> <p>The best way to propose new UI improvements for Drupal is writing proof-of-concept modules. It would be great to get some of those done during a focussed Usability Sprint.</p> <p>So, how's this for an ideal usability sprint scenario:</p> <h4>BoF Usability Sprint Day 1</h4> <ul> <li>zoom in on 1 or 2 issues we already decided upon before the conference<br /> (redo admin categories, modules page, permissions page…)</li> <li>bring your ideas and proposals</li> <li>discuss the options, decide on 1 or 2 things we can work on.</li> </ul> <p>example:<br /> - do a card sort on the admin categories<br /> - discuss the different 'dashboard' approaches people already use<br /> - choose 2 options we want to compare / test</p> <p>another example:<br /> - let's pick a nice chunk of core interface text: labels, descriptions, help<br /> - rework them for clarity, consistency and brevity.</p> <h4>BoF Usability Sprint Day 2</h4> <p>build prototypes: on paper, in photoshop and/or code<br /> or: further work on interface copy, start documenting the copywriting guidelines we find.</p> <h4>BoF Usability Sprint Day 3</h4> <p>Test conceptcode with the Usability Testing Suite<br /> or: create patch for interface copy and start the guidelines handbook page on drupal.org</p> <p>Related issues and discussions:<br /> - <a href="http://drupal.org/node/191360" title="http://drupal.org/node/191360">http://drupal.org/node/191360</a><br /> - <a href="http://drupal.org/node/228236" title="http://drupal.org/node/228236">http://drupal.org/node/228236</a><br /> - <a href="http://drupal.org/node/270919" title="http://drupal.org/node/270919">http://drupal.org/node/270919</a><br /> - <a href="http://drupal.org/node/222036" title="http://drupal.org/node/222036">http://drupal.org/node/222036</a><br /> - <a href="http://drupal.org/node/239715" title="http://drupal.org/node/239715">http://drupal.org/node/239715</a><br /> - <a href="http://drupal.org/node/108979" title="http://drupal.org/node/108979">http://drupal.org/node/108979</a><br /> - <a href="http://groups.drupal.org/node/12618" title="http://groups.drupal.org/node/12618">http://groups.drupal.org/node/12618</a><br /> - <a href="http://groups.drupal.org/node/12507" title="http://groups.drupal.org/node/12507">http://groups.drupal.org/node/12507</a></p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/12972#comments Designers and Information Architects Usability Mon, 07 Jul 2008 12:55:05 +0000 yoroy 12972 at http://groups.drupal.org http://groups.drupal.org/node/12920 <p>Story to Article seems to have been a good move (and people who haven't tried out a new D6 yet keep suggesting it again all over the place).</p> <p>However page is still there, and according to both UMN and UB testing, causes conceptual problems for a lot of people.</p> <p>I took a quick look at wordpress - which has 'posts' and 'pages', here's what they've got to say for themselves:</p> <p><a href="http://codex.wordpress.org/Pages" title="http://codex.wordpress.org/Pages">http://codex.wordpress.org/Pages</a></p> <p>There's also a slightly dusty patch here to rewrite the descriptions (again): <a href="http://drupal.org/node/233200" title="http://drupal.org/node/233200">http://drupal.org/node/233200</a> and which I'm planning to resurrect.</p> <p><a href="http://www.nicklewis.org/node/973">Nick Lewis</a> also suggested throwing away 'pages' as they are now, and letting the book module take it over - then we get hierarchy built in. Note wordpress appears to offer some kind of page hierarchy out of the box.</p> <p>We could enable the book module by default (a renaming wouldn't hurt, but that's another issue), and then make that the second content type - would be much more differentiated compared to 'article'. Note that there's already tags by default for articles in D7, and soon there'll be an 'expert' install profile with almost nothing in it - so we should feel free to bloat the default install profile a little bit for central issues like these. I've used book module for an about section on one site, so does <a href="http://www.raincitystudios.com/book">Rain City Studios</a> - and that's what we're currently telling people to use 'page' for. Seems like a good start to me.</p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/12920#comments Usability Fri, 04 Jul 2008 16:45:14 +0000 catch 12920 at http://groups.drupal.org http://groups.drupal.org/node/12739 <p>From the <a href="http://www.informationweek.com/blog/main/archives/2008/06/getting_started.html">Information Week</a> article on Drupal.</p> <blockquote><p>It assumes that you know very little about running servers, setting up a database or tweaking PHP, and instead gives a step by step walkthrough for setting up your first site. <em>This is the kind of new-user-friendly attitude that the Drupal community exudes.</em></p></blockquote> <p>(emphasis mine). This is much more positive about the ease of installation than any other industry magazine review of Drupal I've seen. I know there's more work to do, but we should also celebrate the success of things like the very simple and powerful multi-page installer.</p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/12739#comments Usability Thu, 26 Jun 2008 13:18:38 +0000 greggles 12739 at http://groups.drupal.org http://groups.drupal.org/node/12618 <p>There are numerous usability issues centred around the administration of nodes. Of particular interest in this discussion is the admin/content/node page. The aim of the discussion is to identify the problems, propose solutions and then break those solutions down into specific tasks that we can put into the issue queue.</p> <p>The discussion really began at <a href="http://groups.drupal.org/node/12507#comment-40213" title="http://groups.drupal.org/node/12507#comment-40213">http://groups.drupal.org/node/12507#comment-40213</a>, and so the points made there are summarised below. (An issue has also been created at <a href="http://drupal.org/node/270912" title="http://drupal.org/node/270912">http://drupal.org/node/270912</a>, but we will probably have to implement several issues to fix this.)</p> <p>Our priority should be to fix a 'major' issue found in the University of Baltimore study of May 2008 (<a href="http://groups.drupal.org/node/12447" title="http://groups.drupal.org/node/12447">http://groups.drupal.org/node/12447</a>). Issue 11 states:</p> <blockquote><p> Participants found it difficult to find content once it had been created. </p> <p>Participants attempted to use the create content link to try and find existing pages - expecting more from the link </p></blockquote> <p>The obvious solution is to provide a clear link back to the admin/node/content page. For users with 'administer nodes' permissions, this link does exist in the navigation menu and on the main /admin page, however it appears that users have difficulty finding it so we need to consider how we can make this more visible.</p> <p>However, this also raises another issue. For any users who do not have 'administer nodes' permissions this solution is useless since they will be denied access to the admin/node/content page. The link will also disappear if the 'access administration pages' permission is off for that role.</p> <p>In order to obtain some focus, we should consider first working on improving the actual admin/content/node page, and then progress to solving the problem of solving this page afterwards.</p> <p>In addition to the permissions problem, the filtering user interface is confusing. The solution to the filtering mechanism will likely be related to how we solve the permissions problem.</p> <p>There is also a desire for more granular permissions for changing sticky, published status, comment settings, etc. (for example <a href="http://drupal.org/node/214190" title="http://drupal.org/node/214190">http://drupal.org/node/214190</a>).</p> <p>One solution (proposed by kingmoore) is for admin/content/node to be a list of content types and for admin/content/node/[type] to display the actual table of nodes for each content type separately. This may require a page showing <em>all</em> content types (for example at admin/content/node/all). It would also require the user to navigate through another screen, which could be annoying if accessing this page is a frequent task for the administrator.</p> <p>The implementation of 'update options' on this page has also be brought up as needing attention.</p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/12618#comments Usability Sat, 21 Jun 2008 03:17:45 +0000 alpritt 12618 at http://groups.drupal.org http://groups.drupal.org/node/12507 <p>The plan is to solve the following problems:</p> <ul> <li>New installations provide a set of instructions on how to set up a site. But this disappears as soon as you put something on the front page.</li> <li>When users upload content, they frequently lose it</li> <li>When new things happen on the site (e.g. actions are triggered, comments get posted), users have to click all around the place to find out what has happened.</li> <li>There is very little distinction between a site builder and a site administrator.</li> </ul> <h3>Administrator or Site builder or Both</h3> <p>The admin interface has to be flexible. It is used by a wide range of users. For simplicity I want to isolate three different types of users here:</p> <ol> <li>There are the expert Drupal developers who are involved in the construction of the site. These people see the welcome message instructions regularly and ignore them because they already know what to do.</li> <li>There are the administrators of the final site, doing day to day activities such as creating content, moderating comments and forum posts, blocking IP addresses, etc. These people never see the welcome message because the site has already been created.</li> <li>There are people who do both, but who are not expert developers. Drupal is not their day job, they just want to create a site for themselves. These are the people who read the welcome message instructions and use them as a guide.</li> </ol> <p>The focus here is on improving the admin interface for users 2 and 3 without disrupting 1.</p> <h3>Flexibility</h3> <p>If we are to cater to the site administrators, the /admin section needs to be flexible. The site builder needs to be able to say what the final user can see, and what they can't see.</p> <p>Drupal can already do this through the permission system. But there are problems with the implementation. The main issue, is that permission to view the administer menu for authenticated users is <em>off</em> by default. In its current implementation this is the correct behaviour, since the admin menu is not really built for a simple authenticated user (someone who can only create forum posts, as an extreme example). Instead, we give these people options on the /user section of the site. But this does not gracefully scale as new permissions are added. For example, on drupal.org I am a member of the docs team. That gives me the rights to edit most pages in the handbook. However, to keep track of new content we have to write a php script that displays a page of latest contributions (<a href="http://drupal.org/handbook/updates" title="http://drupal.org/handbook/updates">http://drupal.org/handbook/updates</a>). In a sense this does a similar job to admin/content/node. But we can't provide access to it because permission to that page allows users to edit all content.</p> <p>There is another issue too. For example, if access has been granted to see admin/content/node, but not to access the /admin pages you have to type in the url directly to see it. This is a potential security risk because it hides the fact that a user has been granted access to a page (you only know because of a checkbox) making mistakes more likely. It also forces site builders to create a link to it manually (unless they want to keep that page orphaned).</p> <p>So what happens when you turn on permissions to access the administer pages? Well, it creates the top level menu items and shoves them in your menu even if those sections are empty for that user. So if you restrict all rights to items in the 'Site building' menu that menu section becomes empty, but the user still has a menu item in their navigation screen. For security reasons, it's a good idea to create a separate admin account for day to day operations which does not allow access to site construction tasks. You can't currently do this is a clean fashion.</p> <p>In the reworked design, the default would be for all authenticated users to have access to /admin as default. If all you have permissions for are the forums, this still has something useful for you. In contrast, if you are user 1 you will have a whole load more options to play with. And access can be turned off completely, if the site builder decides they want to provide an alternate mechanism for their authenticated users.</p> <h3>Welcome screen instructions</h3> <p>The first screen a user sees after installing Drupal is a set of instructions explaining how to set up the site: <em>choose a theme, choose some modules, add some content.</em> One big problem is that it disappears as soon as content is promoted to the front page. Something you rely on shouldn't disappear.</p> <p>And some users never see it at all. If you hire someone to build a site for you, only the dev shop will see these instructions. We still need to make it clear to them, how to make changes to their site.</p> <p>The solution is to make the admin interface clear enough that you don't need the instructions.</p> <h3>Where's my content?</h3> <p>Our usability studies have shown that users lose content easily. If a role doesn't have permission to administer content, there are circumstances where there is actually no way of finding the content again, except for guessing the url. There are many ways for the site builder to create ways of finding content again (tracker, taxonomy pages, views, menu items), but there are still two issues. 1. There is no good default. 2. There's no central location to find this stuff.</p> <p>The answer to the question, then, is always to go look at the admin dashboard. Site builders can break this answer if they wish and provide and alternative, but the aim is to make this the default.</p> <h3>Design vs flexibility</h3> <p>Currently /admin is one big menu all laid out on one page. From a usability standpoint this is actually a pretty good design. It allows users to scan for the exact content they want without doing a lot of clicking and page refreshes. In most cases this is not too overwhelming because we stick to under seven menu items per category. 'Site configuration' is the exception; it has become the big bin to put stuff in when we haven't worked out how to integrate them properly elsewhere in the UI. 'Logging and alerts' and 'Administration theme' are prime examples that don't really belong here. But there are issues elsewhere as well ('Post settings' under Content Management, for example). There is room to tidy things up here, and turn a sea of links into a lake at the very least.</p> <p>One problem with a long list of links, is it very difficult to memorise the layout of the page and get fast at navigating. In a thread on dashboards, Amazon pointed out that <a href="http://groups.drupal.org/node/9570#comment-37406">the new Wordpress interface contains distinct navigation regions</a>. The reason this is a good design is that it provides more context for memorising and recognising the separate admin areas. To get fast at using a screen this recognition part is really important because it gives you the opportunity to avoid re-reading stuff. For example, when I search for the Modules configuration menu item, I instantly know where 'Site building' is because it is always top right. The simple design choice of having two columns makes navigation faster because it gives us one extra dimension for memorising placement of something in space.</p> <p>The advantage that Wordpress always has over us, however, is it specialises in blogs. That means the UI team can really spend time optimising the admin screens so that they fit the rather tightly defined design objectives. Drupal, on the other hand, has to fit many use cases as well as many different drupal themes. This makes our task a lot harder.</p> <p>Still I think we can aid navigation by making each section more visually distinct. I'll leave specifics alone until we get down to specific designs at a later date. But that's one design goal.</p> <h3>Dashboard vs menu</h3> <p>The big problem with a simple menu is that it doesn't allow input or give feedback. It is simply a navigation system, pointing us to various places where we can do things elsewhere. I'm less concerned about input (though it is worth thinking about), but feedback is really important. In our current state, if any activity happens on the site that we need to know about we have to go looking for it. Comments are a prime example. Out of the box, there is no clear way to see when someone has posted a comment to our site. We have to look in admin/content/content and then admin/content/comment/approval. That's fine if you only need to check up on one thing, but that is rarely the case.</p> <p>Another good example is update status which currently uses drupal_set_message() when it wants to inform you of out-of-date modules. These status messages are really designed to display feedback on your last operation. If we start adding persistent messages here, then this is going to muddy the status message waters.</p> <p>So the aim is to allow modules to provide feedback to the admin screen, relevant to the user. This is the authenticated user's home page and when they arrive at it, it tells them what they need to know. In other words, we need to create a dashboard.</p> <p>Again, flexibility is important. Nobody on drupal.org, for example, wants to be informed every time a comment is made. Also performance concerns need to be taken into account. So this should be completely configurable, probably integrate with Actions and it will require an API.</p> <h3>What about /user?</h3> <p>I've been considering where this dashboard stuff really belongs. Some menu items are user specific so in a sense they belong in the /user section. On the other hand, many admin roles are not user specific. One aim here is to give authenticated users a single place to go that they they can call home. Having /user <em>and</em> /admin breaks that idea.</p> <p>Where a separation may make sense, is between site building and site administration. But I'm not convinced that is such a good idea either.</p> <p>So I'm proposing that /user and /admin combine. Obviously we need a separate place for user profiles, but not every site even makes use of that. What I'd like to get rid of is this default almost-blank /user page when we login and provide users with a useful administration screen instead.</p> <h3>Going forward</h3> <p>The above is basically a brain dump of stuff I've been thinking about for the past six months or so. It is not, therefore, anywhere near a complete or detailed enough propal. I'm simply after feedback on the initial idea and suggestions. There are many perspectives to look at this from, if this is going to be well designed.</p> <p>Let's sum up what I'm proposing so far:</p> <ul> <li>by default all authenticated users get access to some form of /admin</li> <li>modules can hook into /admin and provide feedback to the user (the dashboard)</li> <li>sections of /admin can be turned on and off through the permission system (we have this, but it needs cleaning up)</li> <li>editing your own account happens under /admin not /user</li> </ul> <p>[editing to add... if anyone feels like <strong>including images in the comments of this thread</strong>, can you please link to them rather than imbed them. I've found they tend to dominate the discussion too much in other threads and also it blocks the intertubes with heavy page loads. Cheers! :)]</p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/12507#comments Usability Tue, 17 Jun 2008 14:09:01 +0000 alpritt 12507 at http://groups.drupal.org http://groups.drupal.org/node/12447 <p>Attached are the results from the usability study I did for at the University of Baltimore. This was for the Research Methods class with Professor Kathryn Summers - we did usability testing with an eyetracker and looked at the results.</p> <p>What I found most pressing was that all of our participants had a lot of frustration due to not understanding that the administrative functions overlayed the website itself. It made seemingly simple tasks much more difficult for them to grasp. I had one case where a participant explained to the moderator after the test was over that some CMS's have an admin that overlays the site, yet still didn't get that that was what he had been looking at for the past hour. I think any push towards integrating more contextual clues or help and creating more visual feedback that a user is within the administrative portion of the site (like a dashboard) will be a great help to new users.</p> <p>I'd be happy to post the session videos - any recommendations on where to put them would be appreciated.</p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/12447#comments Usability Sat, 14 Jun 2008 17:08:22 +0000 beccascollan 12447 at http://groups.drupal.org http://groups.drupal.org/node/12118 <p>Vast progress on <a href="http://groups.drupal.org/node/8707">Inline/Wysiwyg API</a>:</p> <p>After digging through TinyMCE module's issue queue and finding some RTBC patches containing major improvements to the module, languishing in the queue for more than one year (!), I decided to fork TinyMCE module into <a href="http://groups.drupal.org/node/8707">Wysiwyg Editor</a> module. Most importantly, I've implemented Nedjo's patch to <a href="http://drupal.org/node/118747">use jQuery to initialize the editor</a>. This was an important step in the right direction, because Wysiwyg's goal is to support not only TinyMCE in the future.</p> <p>However, for now the most exciting new feature is: I've re-rolled my <a href="http://drupal.org/node/152046">hook_wysiwyg_plugin()</a> patch, which allows <strong>any module in contrib</strong> to add its editor plugins to the editor configuration. So the time of installation steps like the following in Image Assist's README.txt is finally over now:</p> <div class="codeblock"><code>-- TINYMCE PLUGIN INSTALLATION --</p> <p>If you use the TinyMCE WYSIWYG editor, you need to install a plugin for Image<br />Assist.</p> <p>* Move or copy the folder &#039;drupalimage&#039; in the img_assist directory to</p> <p>&nbsp; [sites/all/]modules/tinymce/tinymce/jscripts/tiny_mce/plugins/<br />&nbsp;&nbsp; <br />&nbsp; Edit the file plugin_reg.php in the tinymce directory. It&#039;s located in:</p> <p>&nbsp; [sites/all/]modules/tinymce/plugin_reg.php</p> <p>&nbsp; Add the following lines anywhere above the &#039;return&#039; statement (without the<br />&nbsp; &amp;lt;code&amp;gt; tags):<br />&amp;lt;code&amp;gt;<br />&nbsp; $plugins[&#039;drupalimage&#039;] = array();<br />&nbsp; $plugins[&#039;drupalimage&#039;][&#039;theme_advanced_buttons1&#039;] = array(&#039;drupalimage&#039;);<br />&nbsp; $plugins[&#039;drupalimage&#039;][&#039;extended_valid_elements&#039;] = array(&#039;img[class|src|border=0|alt|title|width|height|align|name]&#039;);<br />&amp;lt;/code&amp;gt;</code></div> <p>Besides the <a href="http://drupal.org/node/152046#comment-875901">example snippet for Paging module</a> (requires former drupalbreak plugin as a subfolder of Paging module), there's already a <a href="http://drupal.org/node/179712">patch for Image Assist</a>, too.</p> <div class="og_rss_groups"><a href="/wysiwyg">Wysiwyg</a></div> http://groups.drupal.org/node/12118#comments Usability Wysiwyg Mon, 09 Jun 2008 19:26:00 +0000 sun 12118 at http://groups.drupal.org http://groups.drupal.org/node/12078 <p>We know we have a workflow issue when a user mutters "what do I do now!?" and spends the following ten minutes looking through random menus looking for an answer. A user will also frequently declare themselves 'stupid' once they find what to do; <em>how did they miss this one simple step?</em> But this is not down to stupid users; it is a design problem. Drupal has too many of these problems and we need to fix them.</p> <p>The purpose of this page is to document these workflow issues so that we can try to understand the extent of the problem Drupal has a rather large challenge as the large user-base diverges in its level of knowledge and ideas for using Drupal; which makes creating the right work flow for everyone difficult.</p> <h3>Identifying problems</h3> <p>We should look for specific user tasks and instead of going through parts of the workflow we should go from step 1 : finding the tasks function to step x : finding the tasks results. Example tasks include:</p> <p>I want to remove the byline from my pages<br /> I want to enable comments on my blog<br /> I want to add a new forum</p> <p>We only want to list tasks which research or experience has showed there are workflow issues. We want to list the obvious problems where users get stuck. We are not looking for UI problems that make a task more difficult than it should be (too much clicking, for example), but are instead looking for areas where the user can't figure out where the next step is; or even where the first step is.</p> <p>Please help. This is a wiki!</p> <h3>Resources:</h3> <p><a href="http://www.cooper.com/insights/journal_of_design/articles/going_with_the_flow_interactio_1.html" title="http://www.cooper.com/insights/journal_of_design/articles/going_with_the_flow_interactio_1.html">http://www.cooper.com/insights/journal_of_design/articles/going_with_the...</a></p> <h3>Problems</h3> <ul> <li><a href="http://drupal.org/node/222036">Enable user pictures for displaying in posts</a> – Enables user pictures without a problem, but does not know to go to admin/build/themes/settings to actually display them in a post.</li> <li><a href="http://drupal.org/node/161085">Install a contributed module</a>. After enabling a module, what is the next strep? The user needs to know the concept of the mode (in more detail than on the project page), what permissions and settings are available, what other tasks should be performed (e.g. create content type, create role, etc.) to install the module. Currently there is no indication whether the module has it's own permissions or where the settings page/s is/are.</li> <li><a href="http://drupal.org/node/270912">Where is my content?</a> - It's easy to create content, thanks to the link at the top of the admin block. But it's also easy to overlook the settings hidden in the collapsible fieldsets, so new users may end up creating a content without giving it a menu item, a taxonomy, or promotion. Of course there's a contents list but it's buried three levels down into administer/content management/content, which is not obvious when you're not used to the admin interface.</li> <li>Clicking a link for help in the middle of a form means users risk losing the content of that form.</li> <li>The welcome text explaining how to set up the site disappears as soon as content is published to the front page.</li> <li>Users can't easily find how to change the default contents of the front page. The setting to change this is stuck at the bottom of admin/settings/site-information. On the other hand, sometimes content gets published there (when content is promoted) and they don't quite understand why.</li> <li>A module (search for example) seems to be working, but when the user logs out it ceases to work. Permissions are pretty straight forward to fix, but only when the user realises that this is the problem</li> <li>User disables login box or puts the site into offline mode. Now they don't know how to log back in. We've trained them to use something that can disappear.</li> </ul> <div class="og_rss_groups"><a href="/usability">Usability</a></div> Usability Sat, 07 Jun 2008 00:47:17 +0000 alpritt 12078 at http://groups.drupal.org http://groups.drupal.org/node/11992 <p>Continuing discussion from <a href="http://groups.drupal.org/node/11011" title="http://groups.drupal.org/node/11011">http://groups.drupal.org/node/11011</a></p> <p>I have exchanged a number of emails with a reseller of Morae in Australia (they cover sales in my geographic region). They say there are no academic or non-profit discount on Morae. I didn't ask about bulk-purchase. It would be interesting to see if Techsmith (or their US reseller) also says this. Prices they quoted were in AUD and approximately equivalent of those published in USD on <a href="http://www.techsmith.com/purchase/default.asp" title="http://www.techsmith.com/purchase/default.asp">http://www.techsmith.com/purchase/default.asp</a></p> <p>Additionally, there appears to be some confusion about the Morae group of products. There are three individual products:<br /> * Morae Recorder; Needs to be installed on the participant's machine -- transferable license. USD 195<br /> * Morae Observer; Needs to be installed on the observer(s) machine(s). USD 195<br /> * Morae Manager; Not required to record or watch in real time (not sure about afterwards) but is useful to analyze data, create graphs, manage multiple studies, tests, participants and sets of data, build a list of issues, export data to client / design team etc.. USD 1295</p> <p>Bundles are available of all three products; USD 1495 (currently discounted), or just Observer/Recorder; USD USD 349.</p> <p>For Drupal's needs, manager is not likely worth the add'l USD 1100. However my goal in the UTS is to be able to do this stuff for FREE, without requireing Drupal Usability community members or other entities to "own" software.</p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/11992#comments morae Usability Testing Usability Wed, 04 Jun 2008 10:27:23 +0000 Bevan@drupal.org 11992 at http://groups.drupal.org http://groups.drupal.org/node/11921 <p>There may have been discussion about this before, but I'm not aware of it. I know there's a similar discussion about the word "node."</p> <p>Something I like to do just to see how "usable" my site is, is to watch someone register and try to use the site without giving them any help. I was doing this the other day, and a user went to edit her profile. Everything was fine until she got down to the section where you can enable or disable blocks; she just skipped it. I asked why, and she said she was confused; she thought "blocks" would "block" information.</p> <p>That sounded logical to me. Blocks should block. Blocks as Drupal uses the word are more like blurbs - blurbs of information.</p> <p>So: thoughts? Suggestions for a new word for "block"?</p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/11921#comments block blocks Usability Mon, 02 Jun 2008 04:19:30 +0000 IceCreamYou@drupal.org 11921 at http://groups.drupal.org http://groups.drupal.org/node/11863 <p>I'm a GSoC student for 2008. My project is <a href="http://drupal.org/project/usability_suite">Usability Testing Suite</a> and I have created a <a href="http://drupal.org/node/264398">flow for how I think it should work</a> and would like feedback as to the viability of it.</p> <p>Please comment on the issue, not this discussion.</p> <p>Thanks.</p> <p>Project schedule and status: <a href="http://groups.drupal.org/node/11011" title="http://groups.drupal.org/node/11011">http://groups.drupal.org/node/11011</a></p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/11863#comments usability SoC 2008 Usability Thu, 29 May 2008 22:54:09 +0000 boombatower@drupal.org 11863 at http://groups.drupal.org http://groups.drupal.org/node/11791 <p>Access Control Page does its Job - one big scrolling Motogp, but at least serial and logical. Still I hate scrolling and like the idea of how much can be put on one page but still distinguishible. For Comparison check Joomla Admin pages - they overdo it, in my opinion, but it is amazing how much you can physically put on a page just by use of smaller fonts and color coding. So this is what I basically use.</p> <p>It is my second attempt at access Control Page - something quite similar is buried in some issue... ;) I aim at having it integrated with module activation, if this does not overload the UI. If a module is greyed out here this may mean that there have no rights been set and only Admin can see it. But it might also indicate that the module is not activated at all. Gonna figure out later. Hopefully <strong>image-1</strong> is fully self-explanatory (wasn't it if you gotta explain it it is still too complicated?) But sure: If the Initial of a Role is visible, it has access to the adjacent feature of the module. I added extra dashes if the module is not greyed out to make it easier distinguishable which is enabled and which not.</p> <p>I delibarately and malevolently deny any CSS boundaries, this is how I would like it to look like. For the self-adjusting columns I once saw a solution: there was a javascript module that did the trick. Would have to make it a jquery plugin to do the trick. I had quite a large number of modules installed (nasty Ubercart), so i preferred tabbed pagination over scrolling (as I mostly do ;) )<br /> Hers is Multicolumn Javascript: <a href="http://randysimons.com/overige/multicolumn/" title="http://randysimons.com/overige/multicolumn/">http://randysimons.com/overige/multicolumn/</a></p> <p><strong>image-2</strong> shows what you see clicking on any point inside a module: the big Javascript Popup comes up, so one can click Fields more easily. Due to a somewhat sloppy Implementation of mine the Letters do not even match the Initials of the Role names neither does the number of five on the overview match four in the big window - but you get the idea. F</p> <p>For those who say: but If I want to work on several modules at once - well, look at <strong>image-3</strong>. This might be a Javascript nightmare to put into reality, but it would sure be nice.</p> <p>Images are quite big, more than 900px wide, sorry. But should be viewable...<br /> Funny, only one is taken.<br /> More here:<br /> <a href="http://netzschwimmer.de/dateien/drupal/gdo/Image-2.jpg" target="_blank">Image-2</a><br /> <a href="http://netzschwimmer.de/dateien/drupal/gdo/Image-3.jpg" target="_blank">Image-3</a></p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/11791#comments UI Design UX Usability Interface Access Usability Wed, 28 May 2008 01:25:23 +0000 eigentor 11791 at http://groups.drupal.org http://groups.drupal.org/node/11691 <p>I just opened up two issues:</p> <ul> <li><a href="http://drupal.org/node/261869">Default tags vocabulary</a><br /> *<a href="http://drupal.org/node/261882">'Advanced' install profile</a></li> </ul> <p>The idea is to get more dummy content into the default profile, whilst at the same time provide a stripped down profile for people who don't need it. The question is, what else could we put in the default profile if we're able to bloat it a little?</p> <p>Enable more modules? Which ones?<br /> Dummy content in page nodes and dummy primary links pointing to them?<br /> Dummy article posted to the front page?<br /> Dummy 'categories' vocabulary with a select list?</p> <p>I'll admit to knowing very little about the install profile system, and it might get overhauled itself during D7. But it'd be good to get a list of things that might be helpful to have examples of when you first install Drupal, and see which of those we can squeeze in to the default profile without making it too annoying.</p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/11691#comments Distribution profiles Improvements to core Usability Fri, 23 May 2008 10:42:20 +0000 catch 11691 at http://groups.drupal.org http://groups.drupal.org/node/11678 <p>So, for GSoC, my project is, for lack of a better name, <a href="http://groups.drupal.org/node/10893 "> Plugin Manager</a>.</p> <p>It's designed to retrieve a list of all modules and themes available for the version of Drupal that a server is using. It then allows the Drupal administrator to automatically retrieve and install the modules and themes they desire (as well as their dependencies). Just to be perfectly honest, the group that I want to cater to the most is the group that wants a website and has no idea what tar.gz means.</p> <p>These are four mock shots that have to offer.</p> <ol> <li><a href="http://geektownhall.com/screenshots/search.jpg">http://geektownhall.com/screenshots/search.jpg</a></li> <li><a href="http://geektownhall.com/screenshots/viewmodule.jpg">http://geektownhall.com/screenshots/viewmodule.jpg</a></li> <li><a href="http://geektownhall.com/screenshots/viewtheme.jpg">http://geektownhall.com/screenshots/viewtheme.jpg</a></li> <li><a href="http://geektownhall.com/screenshots/install.jpg">http://geektownhall.com/screenshots/install.jpg</a></li> </ol> <p>The first is when the user is trying to find a module.<br /> The second one is of the user looking at search results for a module.<br /> The third one is looking at the available themes.<br /> The last one is the actual installer.</p> <p>Any suggestions on what I should do to make this most usable?</p> <p>Thanks for you time,<br /> Joshua Rogers</p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/11678#comments SoC 2008 Usability Fri, 23 May 2008 05:27:06 +0000 JoshuaRogers 11678 at http://groups.drupal.org http://groups.drupal.org/node/11661 <p>Taking a look at the support forums in response to <a href="http://www.elvisblogs.org/drupal/quicker-drupal-adoption-10-minute-challenge" title="http://www.elvisblogs.org/drupal/quicker-drupal-adoption-10-minute-challenge">http://www.elvisblogs.org/drupal/quicker-drupal-adoption-10-minute-chall...</a>, it occurred to me that it's a prime place to find usability issues. So I figure a thread for posting them up might be worthwhile. Fixable ones should probably be accompanied by an issue nid as well:</p> <p>Here's one to start:</p> <p>Edit any page permission doesn't allow you to edit <em>any</em> page:<br /> Forum topic: <a href="http://drupal.org/node/261498" title="http://drupal.org/node/261498">http://drupal.org/node/261498</a><br /> Issue: TODO</p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/11661#comments Usability Thu, 22 May 2008 14:05:47 +0000 catch 11661 at http://groups.drupal.org http://groups.drupal.org/node/11542 <p>I've come up against a usability problem that I think is caused by a problem in Drupal's data model.</p> <p>Example of problem: When setting block visibility settings, it is impossible (without writing custom php), to make a block visible to authenticated users who have no other role, if you <em>don't</em> want that block to show to <strong>all</strong> authenticated users. In other words, you may want to show the block to all authenticated users except those of belonging to role x. No can do without php.</p> <p>That's just one simple example. But the problem exists anytime one sees "authenticated user" in a list with other roles because "authenticated user" doesn't mean the same thing as other roles in the list.</p> <p>One approach toward solving this would be to require the assignment of a role for each user upon registration. Site admins would be required to define a default user role. All authenticated users would be required to have at least one role. Maybe some of the code from the <a href="http://drupal.org/project/autoassignrole">Auto Assign Role</a> module could be used for this.</p> <p>Meanwhile, "anonymous user" and "authenticated user" would be pulled out of the roles table. Drupal doesn't use the roles table or the user_roles table to determine whether a user is anonymous or authenticated. It relies on the sessions table for that.</p> <p>It's clearly important that "Anonymous users" should still show up on any lists determining visibility, permissions, etc, but it should be possible to provide that functionality without having "anonymous user" still in the roles table. But even if anonymous user needs to stay in the roles table, seems like "authenticated user" really needs to go.</p> <p>This topic must have been discussed at length somewhere else, but my searches didn't yield anything.</p> <p>Curious to hear your responses and/or references to other places where this issue has been discussed.</p> <p>Shai<br /> <a>content2zero</a></p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/11542#comments database roles Usability Sun, 18 May 2008 04:11:43 +0000 Shai 11542 at http://groups.drupal.org http://groups.drupal.org/node/11385 <p>This usability aims page was initially written as a subsection of a page in April, 2005. <a href="http://drupal.org/usability-aims" title="http://drupal.org/usability-aims">http://drupal.org/usability-aims</a></p> <p>During the preparation for Drupalcon Boston, Neil, Dries, and I spoke with <a href="http://www.uie.com/about/consultants/">Jared Spool</a> who challenged the Drupal project to establish two practices to improve our user experience. First, he recommended we need to establish our user experience goals, and second we need to watch our users use Drupal every six weeks.</p> <p>After the user experience testing at the University of Minnesota, we prepared the presentation for Drupalcon and focused on user experience goals for the Drupal project. They are defined here: <a href="http://groups.drupal.org/node/9252" title="http://groups.drupal.org/node/9252">http://groups.drupal.org/node/9252</a></p> <p>Is it time to update the Drupal usability aims page with the Drupal user experience goals page? Or do we need more discussion?</p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/11385#comments Usability Sat, 10 May 2008 20:42:32 +0000 Amazon 11385 at http://groups.drupal.org http://groups.drupal.org/node/11217 <p><strong>Still not sure why usability testing is important?</strong> See what a linux hobbyist found in an <a href="http://contentconsumer.wordpress.com/2008/04/27/is-ubuntu-useable-enough-for-my-girlfriend/">informal usability test on Ubuntu</a>.</p> <p><strong>Usability testing</strong> (hereafter "<strong>UT</strong>") is getting a lot of attention in <a href="http://drupal.org">Drupal</a> -- and rightly so IMHO. If we aim to have <a href="http://buytaert.net/drupal-7-timeline">"100%" test coverage</a> on Drupal's code and functionality for Drupal 7, it stands to reason we also need test "coverage" on Drupal's usability. If not, it's far too easy for bad interfaces to be developed that pass all the functional and unit tests, but fail miserably in the real world!</p> <p><a href="http://drupal.org/user/214218">Jimmy Berry (aka boombatower)</a> of GHOP fame plans to take the initial (but giant) steps in this direction in the Google Summer of code 2008.</p> <p>[Continue reading on <a href="http://www.civicactions.com/blog/bevan_rudge">my blog at CivicActions</a>: <a href="http://www.civicactions.com/blog/scaling_up_usability_testing_in_drupal">civicactions.com/blog/scaling_up_usability_testing_in_drupal</a>]</p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/11217#comments SoC 2008 summer of code usability Usability Testing Usability Mon, 05 May 2008 11:10:26 +0000 Bevan@drupal.org 11217 at http://groups.drupal.org http://groups.drupal.org/node/11186 <p>First, for those that don't want to read the full post, here's the "30-second elevator speech":<br /> This post to to discuss using Seleinum with Drupal. Specifically using Maven to run the selenium tests and writing the Selenium tests in Java.<br /> The example code be downloaded from the Workhabit Inc. public repository here: <a href="https://svn.workhabit.com/svn/public/drupal/selenium/trunk" title="https://svn.workhabit.com/svn/public/drupal/selenium/trunk">https://svn.workhabit.com/svn/public/drupal/selenium/trunk</a><br /> One must have the following installed to run:<br /> 1. Firefox<br /> 2. Java 1.5+<br /> 3. Maven<br /> All 3 are easy to install and aquire. Once you download the code from the repository, you can just navigate to the directory and run:<br /> <code>mvn -P drupal integration-test</code><br /> Maven and writing tests are beyond the scope of this blog post.<br /> <em>I'm writing this up for comments, thoughts, and hopefully for others to use and/or contribute.</em></p> <p>Ok, now the long winded version:</p> <p>I've been in the Java world for a bit and I'm now bringing my self back into the PHP/Drupal realm.<br /> With that said on my last project we had to validate ALL code with unit tests, and then we did fully functional integration tests using Selenium.</p> <p>The Build management tool we used was Maven ( way past the scope of discussion here ). However, what I have done is GREATLY simplified down what we used into a very short, simple, and small file which allows one to run Selenium tests out of the box. It uses Maven/Java to do the tests...but, that's neither here nor there.<br /> It is available here: <a href="https://svn.workhabit.com/svn/public/drupal/selenium/trunk" title="https://svn.workhabit.com/svn/public/drupal/selenium/trunk">https://svn.workhabit.com/svn/public/drupal/selenium/trunk</a></p> <p>I know that there is a Selenium module for Drupal...however when I thought about this, I also felt that this was an inherit problem. This dawned on me when I read the link that there is a patch to port it to 5.x. There in lies the problem. As we move versions/etc., we're updating the testing frame-work instep with the item we're testing. E.g. PHPUnit may be at 2.3, and we can still use PHPUnit 2.3 for Drupal 4.7, 5.1, 6.x, etc. However, by tightly integrating the testing frame work into the item we are testing, I feel one is creating a cyclic-redundancy in which the end result is chaos.</p> <h1>Goals</h1> <p>My only goals of this project is 2 fold:</p> <ol> <li>Give a solid base so that anyone can download the drupal-seleinum project and write tests for their drupal site.</li> <li>The community should have an entire suite of tests to test the Drupal installation as a base install ( I have currently started these in the com.workhabit.drupal.selenium.core package. Inside the package, it think they should be split into their subsystems, e.g. Authentication, Taxonomy, CCK, etc.). </li> </ol> <h2>Why Java/Maven?</h2> <p>Well, there are a number of reasons; I will not list/discuss all of them here as they are not really part of this post. But on the short list; Java allows one to set break points where Selenium is running to see why a test may be failing ( it should be noted you can also do this with PHP; if you setup your IDE correct and get xdebug installed/setup correctly also).<br /> Also, by using Maven, one doesn't have to worry about dependencies with the unit testing suite (versions, etc.) as Maven takes care of all of that. Java/Maven will also allow us to do more in terms of continuous-build integration. Further, writing tests in Java is not that much harder/different that writing them in PHP. The Selenium IDE gives code in many languages (HTML, PHP, Java, Ruby, etc.) so anyone should be able to create tests easily. I'm hoping to write a post of how to write/add tests in Java. Most of the hard work has already been setup in the code, so all one has to do for a new test pretty much is create a new class and create an annotated java method, such as:</p> <div class="codeblock"><code>@Test<br />public void myDrupalTest() {<br />&nbsp; BROWSER.open(&quot;/path/to/my/site&quot;);<br />&nbsp; // ....other browser test code from Selenium IDE<br />&nbsp; // ...Assertions<br />&nbsp; return;<br />}</code></div> <p>Also, in the coming days, I shall be adding to this suite a "MockSoapServer". This will allow you to hit a webservice in point (in this case the MockSoapServer), and it will return "canned" results. Maven will fire up both the Selenium server AND the MockSoapServer BEFORE running the test suites. It will then create a report and take down both after the tests are run.</p> <h2>Environment Setup</h2> <p>First things first, you will need to have Maven installed on your local machine in order to use the Drupal-Seleinum tests. Installing maven is very simple and straight forward. See the <a href="http://maven.apache.org/download.html">Apache Maven Site</a> for more information on installing Maven.</p> <h2>Setup your Tests</h2> <p>So, lets be real; Usually when we are developing, we are changing some of the default workings of Drupal; So we will need to have a some-what custom test suite for each site we develop; or at least we will be extending the tests with more/new tests.</p> <ul> <li> *EXPORT* the base Selenium maven build from the Workhabit repository.<br /> <code>svn export https://svn.workhabit.com/svn/public/sandbox/earnest/drupal/drupal-selenium</code> </li> <li>Update the POM (If you are unfamiliar with Maven, ignore this step)<br /> You can update the POM if you want to better describe you project. </li> <li> <h3>Modify the "setup.xml"</h3> <p>You will notice when you download the code that there is a file called "setup-example.xml" in the src/test/resources folder. This file is read by the test suite and contains some general settings regarding your site. The settings are pretty self explanatory. The main ones you will need to change out of the box are:</p> <ul> <li>siteRootPath</li> <li>siteDomain</li> <li>testUsername</li> <li>testPassword</li> </ul> <p>I will hopefully be documenting the settings further, but for now, I apologize that the documentation is a bit sparse. </li> <li>Test to see that you have everything setup correctly by running a maven integration test (Note: All tests are done with the drupal plugin)<br /> <code>mvn -P drupal integration-test</code><br /> This should run the DrupalLoginTest which will bring up your Drupal site, and login a user. </li> <li>Add the package to your own repository.<br /> <code>svn add drupal-selenium &amp;&amp; svn commit -m &quot;Adding the drupal-selenium package to my site&quot;</code><br /> You now have a customized maven/Selenium test suite for the project that you are working on. </li> </ul> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/11186#comments selenium testing Build Systems &amp; Change Management Enterprise Testing and Quality Assurance Usability Sat, 03 May 2008 16:03:04 +0000 Souvent22@drupal.org 11186 at http://groups.drupal.org http://groups.drupal.org/node/11161 <p>There have been a few rounds of discussions on Drupal UX goals/principles this past year, so I thought this announcement would be of interest to the community:</p> <p>"Late in 2007, our User Experience (UX) group—which does user interface design, visual design, user research, web development, and user interface writing—set out to articulate the principles that ought to guide Google designs worldwide. What are the fundamentals that all Google designers and researchers accept? Which approaches to design are particularly "Googley"? How can we encourage teams throughout Google to dream big and make smart design decisions?"</p> <blockquote><p> A small team gathered to discuss these questions and define the Googley Design Principles:</p> <p> 1. Focus on people—their lives, their work, their dreams.<br /> 2. Every millisecond counts.<br /> 3. Simplicity is powerful.<br /> 4. Engage beginners and attract experts.<br /> 5. Dare to innovate.<br /> 6. Design for the world.<br /> 7. Plan for today's and tomorrow's business.<br /> 8. Delight the eye without distracting the mind.<br /> 9. Be worthy of people's trust.<br /> 10. Add a human touch. </p></blockquote> <p><a href="http://googleblog.blogspot.com/2008/04/what-makes-design-googley.html">http://googleblog.blogspot.com/2008/04/what-makes-design-googley.html</a></p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/11161#comments design principles usability Usability Fri, 02 May 2008 17:18:34 +0000 libsys 11161 at http://groups.drupal.org http://groups.drupal.org/node/11154 <p>og_panels is here! And when I look at this <a href="http://groups.drupal.org/drupal-dojo" title="http://groups.drupal.org/drupal-dojo">http://groups.drupal.org/drupal-dojo</a> I gotta say, I get a little envious... With being quite some design people here in this group this page should rather look that good.</p> <p>And it is not only about eye-candy: make the information better accessible by introducing more blocks. I volunteer to provide mockups and do the stuff. But I think we depend on Neill Drumm to get things rolling...</p> <p>Ah, and that's not all. Look here: <a href="http://groups.drupal.org/node/10445" title="http://groups.drupal.org/node/10445">http://groups.drupal.org/node/10445</a></p> <div class="og_rss_groups"><a href="/usability">Usability</a></div> http://groups.drupal.org/node/11154#comments og_panels Usability Fri, 02 May 2008 05:48:37 +0000 eigentor 11154 at http://groups.drupal.org http://groups.drupal.org/node/11092 <p><a href="http://drupal.org/node/102679">Add Display Name field(s) to core in addition to Username</a> is a D7 feature request. This document assists advocators to bring clarity and structure to the proposal and formulate design requirements to pass to core developers. <strong>So, add to this page.</strong></p> <p>Please see <strong>How To Comment</strong> below. Comments are <strong>additive</strong>...</p> <p><strong>Overview:</strong></p> <p>There are many reasons for having <em>Display Name</em> functionality in core: security, ease of setup, consistancy for theme and module developers.</p> <p><strong>Name Fields:</strong></p> <p>These definitions are intended to describe these fields/names so that module and theme developers know where and how to use them in their themes and modules. It seems that a bit of standardisation of "names" terminology could help a lot in bringing "slick" to Drupal:</p> <ul> <li> <p><strong>Display Name:</strong></p> <ul> <li>Also Known As: Real Name</li> <li>Function: Attribution, Authorship</li> <li>Usage: Is intended to appear in web text and not in web links or URLs.</li> <li>Uniqueness: Default setting is not unique (as real names are not unique). Webmaster has option to set this field to unique.</li> <li>Constraints: Webmaster has options to set constraints for: length, numerics, alphas, case, capitalisation, punctuation.</li> <li>Clone: Webmaster has option to set this field to be a clone of the <em>Username</em> field - in which case the <em>Display Name</em> field would equal the <em>Username</em> field.</li> <li>Changeability: Webmaster has option to set whether the user can change this field or not after creation.</li> <li>Defaults: Initially, <em>Display Name</em> field would be set to equal the <em>Username</em> field so as to mimic D6 behaviour.</li> </ul> </li> <li> <p><strong>Username:</strong></p> <ul> <li>Also Known As: Login Name</li> <li>Func