Our UX Principles: 1. Make the most frequent tasks easy and less frequent tasks achievable. 2. Design for the 80% 3. Privilege the Content Creator 4. Make the default settings smart

D7UX – Initial Concepts & Direction

Posted: April 9th, 2009 | Author: | Filed under: Concepts, designing together, Strategy | 73 Comments »

We are really excited to share with you our initial concepts for a D7. Please take a look at the video above and there are LOTS of sketches and paper prototypes that you can explore over on the Flickr group as well.

In this video you’ll see the three key aspects of the D7UX interaction model we are proposing:

  • the ‘header’ which will be displayed to users who are logged into the site, comprising of a ‘global’ header allowing access to all functionality (permissions allowing), and a customisable/role based set of buttons allowing fast access to the most frequently used tasks (eg. add/edit) or views (eg. find content).the example shown in the video would be for a ‘content creator’ type role. We haven’t completely thought through the application of this header down to the level of ‘site member’ (eg. someone who adds discussions to the forum on the site you’ve built using Drupal), but we think as a concept it has legs.
  • the ‘overlay window’, the example of which shown is ‘add content’ (in a very sketchy and unfinished state, I hasten to add!). We see the overlay as a fantastic way to provide a clean interface for these tasks whilst keeping the user in the context of the site for which they are performing those tasks, rather than taking them away into an ‘admin section’. Obviously we would need to allow for users who are not using JavaScript (in which case they probably would have to go into more of an ‘admin section’).
  • the ‘in line editing’ which will allow you to ‘switch on’ edit mode and edit content in place (wouldn’t that be lovely!). Of course, not all content would be editable on the page so the edit view would also allow for a range of ‘editors’ to be launched into an overlay window. We’re imagining: block editors, content type editors, navigation editors, views editors as a start (some of these terms will probably only make sense to Drupallers – apologies for that, will try to translate in future versions)

In the video we also show another idea that we are quite excited about, although we have a long way to go before it is entirely thought through … we’re not entirely sure that it will work, but the problems we are facing with it seem to be getting easier not more difficult, which is a good sign… You could think of this as a Direct Manipulation Tool for Site and Page Structuring. It’s been inspired by some of the tools that we’ve used in the past to do Information Architecture work (hence the use of that word in the initial header that is currently being CrowdTested, yes, it will most likely change!).

The idea behind this tool is that we are able to make site building and page creation a much easier task for people who don’t know and don’t want to know the ins and outs of Drupal’s technical architecture. We’re really excited by the potential this has for achieving our objective of allowing users who are not developers to build complex sites using Drupal… would love to hear what you think of it, and stay tuned for much more work on this component.

We’re  looking forward to pushing some of this out for more Crowd Testing very soon. I’d really encourage you, if you’re concerned about what people will make of this, to get involved in the user research – go put it in front of people and find out for real what people do and what’s usable or not. I’ll post another set of materials and scripts for CrowdSourcedUsabilityTesting very soon!

Ok. So, there you have it.

We’ll just wait here, nervously and excited, whilst you have a look….  then, please, tell us how you like it so far!

73 Comments on “D7UX – Initial Concepts & Direction”

  1. 1 Steve Rollins said at 3:03 pm on April 9th, 2009:

    The direction looks good and am excited to see what develops from the direction. I am concerned though with the multiple levels and the way acl’s will work within them. Though I suppose those details will be worked out shortly

    Nice work

  2. 2 Darren McPherson said at 3:04 pm on April 9th, 2009:


    You both are really taking on the UX. As both were describing the prototype, I was thinking “oh what would be great is, if…” and you would come out and say it. People can tell you both just get it.

    the 2nd part is very complex and will take, as you said more thinking and working out. But if done right (which you both will:D) will be an excellent achievement everyone will admire.

    Good luck guys

  3. 3 Jen Simmons said at 3:15 pm on April 9th, 2009:

    I’m very excited about where Drupal is going, and the work Mark Boulton Design and the Drupal community is doing to improve usability. This is going to change everything. These improvements will make it possible for those of us who build sites for clients to: 1) do so much faster; 2) spend more time making a great site, and less time fixing Drupalwonkiness and handholding clients up the formerly-steep learning curve.

    Thank you Leisa. Thank you Mark. Thank you everyone else who is putting hours and hours into this. I look forward to seeing what happens next!

  4. 4 garrettc said at 3:19 pm on April 9th, 2009:

    There are some really exciting ideas coming out of this process, but you can see the lineage from existing Drupal tools, which I think is really great. The header seems to be a more task orientated admin-menu module, in-line editing is the View/Edit tab system on steroids. Both tools that – as used to them as I am – I’ve still spent more time wrestling with than I’d like. Great work.

    And the Site and Page Structuring tool, ooo, shiny. I can see a lineage from Omnigraffle and other I.A. tools and the idea of canvases and layers. I’m thinking “classes” of page (one column: full width, three column: fat thin thin, etc) with preselected blocks that page instances could inherit from. The “Blog” class always has a “most recent posts” and calendar blocks for example. Perhaps even use-case based. It would be a great way to do away with the ugly regex method of block visibility too.

    I foresee some very interesting possibilities for the novice user, as well as technical improvements that could benefit developers. More ! More! *;)

  5. 5 Alexander Langer said at 3:34 pm on April 9th, 2009:

    The day I read Mark’s gonna be among those who will be asked for working out a new layout / UI for drupal.org I was really really happy and excited because I just knew he would get the job and he would deliver great work.

    This year seeing Leisa and Mark working together on the D7UX is taking things so much further ahead. It’s as exciting as it gets even from a viewer’s / reader’s / listener’s perspective. What you both come up with, backed up by the community, is clean, makes sense and is so simple you have to wonder why nobody else has done it by now. But I guess we all know how hard it is sometimes to get your eyes open and see the very essence of things.

    It’s great to have you on board. We, the Drupal community, are very happy to have you working with us, showing us all the kinds of oddities we’ve been building but don’t realize anymore as they became normal to us – what they shouldn’t. D7UX will make some major impact on the whole Drupal ecosystem, attract new community members, …

    I can already feel it!

  6. 6 Andrew said at 3:41 pm on April 9th, 2009:

    Leisa, Mark,

    In awe once again of the fabulous work you are doing here, and the approach you are taking to the whole d7ux project.

    One observation: the approach you are taking is very visual and I can see personally and from the perspective of other IAs, designers why this would appeal and feel intuitive and a nice way of making Drupal more accessible to a wider base.

    Some developers, and I stress some, I talk you would say that more than anything it’s a simple ‘navigation tree’ style view they are looking for. If you ask them what they don’t like about Drupal and other CMSs, that lack of a ‘tree’ is pretty high up a long list. Something in there about mental models.

    So, my question is whether you see the drag and drop visualisation as one of a number of ways of managing content structure, or as the sole or primary route?

    Keep up the great work – inspiring stuff.

  7. 7 cattlecall said at 3:42 pm on April 9th, 2009:

    Nice interface – looks like a great web-based application for administering Drupal. Can’t wait to see the next steps!

  8. 8 Lisa Bains said at 3:43 pm on April 9th, 2009:

    I love the header idea – every site I have built I have always added a custom header for admins similar to this. I also use the administration menu module religiously for my own user accounts.

    The “Direct Manipulation Tool” is a great idea, although no doubt will be a struggle to implement. The first thing I thought of was book publishing software. I made some books using Blurb’s “Book Smart” software recently and was amazed at how simple it was to create a book layout, which typically would be left to the realm of publishing experts. I can see a similar concept being applied to Drupal, geared specifically towards novice users / content creators. It would be fantastic.

    Thanks for the updates!

  9. 9 Dan said at 3:46 pm on April 9th, 2009:

    Love the ideas. I really hope others are open to a new direction. Those of us that love working with Drupal, but end up spending so much time explaining how to use the system to others, will truly appreciate the simplicity of these new ideas from Lisa and Mark. Thanks for all of the work you are doing and for thinking outside the normal Drupal way of doing things.

  10. 10 Eric said at 3:56 pm on April 9th, 2009:

    I love this idea of a tool for page structure. I’ve been thinking lately of a similar concept, and in my head I called them “layouts.” I like the way your tool works with the content palettes which you can drag from, and also do simple editing to the content on the fly.

    For Drupalers this is sort of like Panels module, but with a different focus, and a lot less complexity than where Panels 2 is going, or at least with that complexity reorganized.

    You can almost achieve this sort of functionality with blocks and regions, but on the blocks page you can only see and interact with the main “layout” (page.tpl.php). This would be like a drag-and-drop blocks admin page that was smart about other template files.

    What if each theme had a layouts folder where at least page.tpl.php lived, but designers could put their page-front.tpl.php, their node-whatevers and custom, reusable templates here. Then perhaps this new site structure tool could draw from that folder and give a list of available layouts to the user.

    I think we’d also need to give the use the ability to designate a path that this layout would live at. Similar to Panels.module I see the ability to choose various layouts (eg 3-column, 2-column, etc.) and give it a path like “/pressroom” then that layout would be used when the user goes there. Path-based layouts would be automatic, like page-front.tpl.php.

    I know this “direct manipulation tool” is such a good idea for Drupal, because a lot of this functionality exists in various modules, it just needs to be brought together in a nice, usable package. Which is where Mark and Leisa come in. (Thanks!)

    For technical reference, I think bits of this new tool’s functionality exist in Panels, and in the Context / Spaces work that Development Seed is doing. (http://www.developmentseed.org/blog/2008/jul/17/introducing-spaces-drupal)

  11. 11 François Granger said at 4:00 pm on April 9th, 2009:

    Really nice set of proposals, make me dream that these are already available ! ;-)

    It remind me of the way Concrete5 works . Try to play with a demo site of it if you can.

    PS: Why do you record in such noisy location ? ;-)

  12. 12 ThatOneGuy said at 4:04 pm on April 9th, 2009:

    This is probably the video you should have opened with. Might have avoided the bad PR the first few generated.

    I like where this is going, but there’s some major technical hurdles involved with that last idea. I know because I’ve been working on it for a while :)

  13. 13 Jim said at 4:05 pm on April 9th, 2009:

    Can you please leave something for us web developers to do! i’m going to be out of a job!

    Seriously though, it looks great. I love the inline editing system on Squarespace, and the way you can switch between admin and user views without committing any information. So this kind of replication in an open source system is fantastic.

  14. 14 Damien McKenna said at 6:12 pm on April 9th, 2009:

    The first two ideas are great, very user-friendly improvements to existing concepts and will be a great addition. The last idea feels very much like what could be achieved by merging Panels into core and simmering it for a while..

  15. 15 Matt Farina said at 7:31 pm on April 9th, 2009:

    Inline editing in drupal is hard but, I still want it. I won’t go into the gory detail here. If you want to read about them you can at http://www.mattfarina.com/2009/04/09/why-inline-editing-in-drupal-is-hard.

  16. 16 Jason Terhorst said at 8:20 pm on April 9th, 2009:

    Adding inline editing is fine with me, as long as there’s a way to turn it off. Personally, I hate the idea, and some of my coworkers need the mental/visual separation when they’re editing a post, versus viewing it… the “frontend” vs. “backend” approach. That’s why I like that I can determine a separate theme for admin pages from the site theme.

    Keeping editing and viewing separate is my ideal environment. This is also how systems like EE and WordPress do it.

  17. 17 Tao Starbow said at 8:51 pm on April 9th, 2009:

    Those are some exciting and ambitious ideas. I wonder if you two have seen what I have been doing with the Popup API modules? It seems similar to what you are thinking about for the overlay. You can see a screencast over at: http://starbowconsulting.com/node/123


  18. 18 Ed D said at 9:33 pm on April 9th, 2009:

    @François Granger that was my thought exactly. Reminds me of Concrete5. If we had a concrete5 like product with the backing of a massive community like drupal; I only see good things coming :)

  19. 19 mac said at 7:44 am on April 10th, 2009:

    I go with the other in expressing my appreciation for the work you are doing.

    It is very fascinating to see the process behind the conception of the user experience.

    The only proposal that does not sound fully convincing to me is the “Direct Manipulation Tool for Site and Page Structuring” (DMT). Maybe it is because it is still in its very early phases, but my first impression is that it risks to create a gap between the logic of Drupal (the software architecture) and the visual representation of information.

    I try to explain: from the video above, I understand the DMT should work very much as a kind of desktop onto which one can dock various widget, something similar to how Yahoo allows the user to customise their homepage.

    That is nice to see, but implies that each bit of information has similar proprieties and that – in essence – a menu is equivalent to a photo, a title to an ad banner and a comment to a search box.

    The problem I see is that Drupal is not designed that way (and this is not a flaw, but the outcome of wise architectural choices), so that “forcing” that level of flexibility would take away efficiency and elegance from “behind the scenes” (which in turn means higher developing and maintenance costs).

    Somehow I see a wizard (i.e. a guided process where the user can pick between various choices at each step) as a better solution over the DMT, as the wizard can limit the choice to those who are “sound” and give the user options who are aesthetically different but logically equivalent.

    Let me clarify further with a metaphor: if Drupal was a restaurant and the user a customer, I see the DMT proposal as “putting the customer in the kitchen”, while I see the Wizard as “giving the customer the menu”. What you really want the user to understand is that caviar is not a dessert, and coffee is not an aperitif, while giving him the choice to compose his own meal , eventually skipping those servings that she/he does not like.

    Anyhow: whatever you will choose to give back to the community as your deliverable, I am sure it will be surely better than the status quo. Keeping on playing the metaphor of the restaurant, I would say that the present state is like “giving the user a folder with the detailed nutritional information of each ingredient used in the kitchen, plus a bibliography of cook books”. :)

    All the best, and looking forward for your next posts.


    PS: I go along with the other user who suggested recording in a quieter location (or to use mikes pinned to your clothes).

  20. 20 Benjamin Doherty said at 4:41 pm on April 10th, 2009:

    Your ideas feel like “common sense.” I really like them.

    Tao Starbow’s mention of his work on Popups API is right on… the lightbox/popup behavior isn’t really the innovation with his module, it’s the direct integration into Drupal menus and forms.

    Inline editing may be easier when everything is a field. The UI can concern itself only with Field API transactions, and Field API can deal with the gory details.

  21. 21 Ronald said at 4:51 pm on April 10th, 2009:

    love the ideas – this is just what Drupal needs. Some serious thought into how we can explain Drupal to users via the way it works rather than via long manual pages.

    There are several challenges with all the features mentioned but I think everything is pointing in the right direction so to answer your question:

    let’s push things forward!

    the final result might change but the journey from this starting point will certainly be exciting

  22. 22 simon r jones said at 5:05 pm on April 10th, 2009:

    love the header tools idea, something I’ve thought would be a good idea for a CMS for a while.

    I was at a client meeting earlier this week and had a tour through their existing CMS (custom built by another agency). This also used the header metaphor to place key actions. And it worked really well.

    However, I think it works better with the main website content administrator than general users who may contribute content to a specific section (i.e. events, directory, etc). I see a separation between site administrators and general users who may contribute content to a specific section. The latter wouldn’t use any of the site management tools so the header thing may be overkill for them.

  23. 23 Sammy Hendrick said at 5:43 pm on April 10th, 2009:

    Great stuff! I’m really interested in the page manipulation tool thingy. I recently a mock up someone had created with this sort of idea for managing blocks in drupal… http://www.jeffnoyes.com/content/drupal-7-usability-improvements-part-ii-blocks

  24. 24 EclipseGc said at 6:19 pm on April 10th, 2009:

    So, let me start by saying the ideas are definitely ambitious. I like some of them, I dislike a couple as well. I’ll try to be constructive in my feedback here.

    1.) Let’s discuss these overlays…

    I don’t mind this approach so much, however I would very much appreciate a detailed explanation of what the non-js implementation would be as well since this one is completely js dependent.

    That said, the rule of thumb I’ve always heard is “If it needs a popup (overlay) it’s probably wrong.” Now if we’re just going to ignore that because we see potential benefits, consider me all on board, I just want to make mention of it before we get too far down the road.

    2.) Editing…

    Ok, I like the idea of inline editing, but I think we have again, a few issues here. Let’s ignore the fact that it’s hard… I don’t see that as relevant. First, we’ve been running headlong into this issue of administrative themes, blah blah blah for a while, and I think this further blurs the boundary of drupal’s administration from its presentation. Again, I’m actually ok with this as I think the feature qualifies as a “killer feature”. But we should carefully consider this point imo.

    The next point on this is the whole click the edit button to enable edit mode. I’m a little confused as to the context of this. You seem to suggest a single edit tab would put the whole page into edit mode. I like this except that it requires me to scroll back up the page to hit edit if I find an error down the page a bit. How would this work in views? Do we really want to edit inline? or could one of your overlays be used for editing? Why do blocks need to be different (assuming they arent’ controlled by php, or some other module that doesn’t allow for a config). I know I’m poking holes in a system you’ve barely got together yet. I think my main complaint is the scrolling back up and back down again.

    3.) Let’s talk about your Page Hierarchy…

    I think a lot of us have been thinking/working on this for a while. The idea for such a thing occurred to me quite some time ago now. Many moons ago I worked within a product called Net Objects Fusion, and NOF had something very similar to this. It didn’t allow for the various page types to be drag-n-dropped but it did build a very nice page hierarchy which would allow me to drag and drop pages under new pages, create/edit/etc. That’s a VERY powerful tool and would be huge I think for Drupal.

    Other have mentioned this already, but what you’re essentially proposing on top of that is the panels module. Panels3 is actually looking very nice at this point and has come a long way. It has a number of advantages over our traditional block system and overall, I think it’s a great idea for ultimately substituting what we have currently. That said, you’re trying to wrap your arms around a Grizzly bear, and the time frames involved may be… well, huge. I’d love to see this happen, I’m just saying that it’s whatever is a bigger word than “ambitious”. That said the workflow you’ve proposed for it is very appealing.

    Good work all around, I would love some answers to my questions in points 1 & 2.


  25. 25 David Geilhufe said at 6:32 pm on April 10th, 2009:

    As I started to wrap my head around the interaction model implied by all of this, I thought it was awfully good for noobs but would make batch operations a pain in the butt… you’d have to edit each piece of content individually.

    So then I started thinking about interaction models basically as applications a drupal user would use to manipulate their sites.

    So something like an overlay is actually one “application” you might use… you might use a different application if the overlay isn’t the right model for your use case.

    So then I imagined you might ship Drupal with a default interaction model which might be far simpler than the one proposed and have a set of core modules that are enabled by default for the super duper interaction model proposed above.

    Keep going on this path, but I wonder if it is not more productive to present this as the optimal interaction model as opposed to the interaction model all of Drupal will follow.

  26. 26 Eric said at 6:41 pm on April 10th, 2009:

    @David —What batch operations are you talking about? Aside from contrib modules, how would users not edit each piece of content individually now?

  27. 27 mbutcher said at 7:26 pm on April 10th, 2009:

    I am thrilled to see the ideas presented here.

    A year or two ago, I was part of the OpenCms community when it went to a Direct Edit model. The release of that capability drastically simplified the process for content creators and editors (while admins often continued to use the more powerful administration interface). It was a huge benefit to the community.

    Both ideas presented here (DMT and the builder) are certainly worth pursuit. Whether they are hard to program or not, these features have got to be worth their weight in gold. A fantastic UX is going to “sell” Drupal to the enterprise, to small website operators, and even to other software developers and themers.

  28. 28 Sammy Hendrick said at 8:40 pm on April 10th, 2009:

    @mbutcher Out of curiosity I tried tracking down somewhere I can see opensource CMS’s direct edit. It seems like it takes over the whole page and isn’t as “inline” as Mark and Leisa are probably planning. http://ecovations.de/people/konrad.wulf/talks/opencms-days-2008/media/screen-recordings/opencms-template-two.swf

  29. 29 merlinofchaos said at 11:59 pm on April 10th, 2009:

    You have successfully described my dream for Panels. :P

  30. 30 @DavidWheelerPhD said at 3:52 am on April 11th, 2009:

    Great work!

    One thing I did not hear you say:

    The Header has to stay visible at the top of the browser Window even when you scroll down through the Page. Admin Menu Module is a rough approximation to a header but it stays at the top of the Page; so, it becomes difficult to easily access.

  31. 31 ben_ said at 10:54 am on April 11th, 2009:

    I think the Header is a great Idea. I think two Aspects of it should be considered.

    1. Context-sensitive Buttons? In some contexts, a different colletions of buttons may be better than the default set.

    2. Alternative to the Header? May the header be replaced by some other sort of “Menu”. I can think of many sites/designs/clients for which a global header doesn’t work.

    I also love the Concept of the Admin-Area as an overlay. One Aspect of that, which I would love to see and which fits into this concept very well – imho – in Drupal Admin is an Ajax-Search which allows you to search for Nodes, Terms, Users and Comments while your doing something else in the admin area.

  32. 32 Mike said at 2:45 pm on April 12th, 2009:

    I love the ideas. A couple thoughts:

    1) The fact that nodes are easily editable in place but views obviously aren’t wouldn’t make sense to a site editor who doesn’t know the difference. Some thought needs to be given on how to differentiate the two.

    2) Obviously, there will have to be some non-JS fallback for the overlays, etc., but I don’t see that as a point against them. Some commenters seem to think that the default should be accessible by everyone…I say make the default as good as possible, as long as it degrades relatively gracefully. It sounds a lot like concrete5 and blueinkcms which definitely isn’t a bad thing from a user-friendlyness standpoint.

  33. 33 chx said at 6:36 am on April 13th, 2009:

    First of all, I am a core coder. My thinking is always on the edge cases. It really must be. So the challenge of inline editing is that currently during the view phase every module has a chance to change what is being viewed. So if you want to edit then the edit code needs to be able to learn what every module put in and edit everything and that mashup of fields that displayed together makes sense might not make too much sense on a single editing screen. Drupal is not the system where a visible piece wall of text has a single source somewhere… that’s another system I won’t name.

    The header, as admin_menu proves is a viable and popular concept, I am quite OK with that actually.

    Now, overlay… I might misunderstand but this is supposed to show admin screens over the website? This is really icky, there are a large number of admin screens which absolutely have no direct and visible effect on one single screen alone and to me they feel natural to be a bit more tucked away and visually separated. It’s a waste of screen space to show these screens over a website page which they do not relate to directly.

    Oh and WYSIWYG on the node add screen. Sure, everyone expects it — I can imagine a helper bar which adds the HTML tags and then you can add a live preview of what you are editing (provided, of course that such a preview actually can be shown when you first edit a field and that might not be a case because of the very same reason i listed in the inline edit part — the additions that are necessary might not be entered — but then this live preview can be just a best effort, a true preview which is not the real thing yet )

  34. 34 mcrittenden said at 6:46 am on April 13th, 2009:


    Excellent point about the inline editing. Content types are often so complicated and turned around by various modules that making the edit form match the result would be a heck of a task.

    Also @chs: Why a live preview over a true WYSIWYG? As long as users are seeing raw HTML, in any way, shape, or form, they are going to run screaming. We need a true WYSIWYG not just on the node add/edit, but also most anywhere that currently has textareas.

  35. 35 chx said at 6:51 am on April 13th, 2009:

    A bit of IRC chat:

    [chx] webchick: I consider it an impossible task to *design* a UI for Drupal core.
    [chx] webchick: a nice, designed, good UI.
    [webchick] chx, I think that’s true. I also think that desiging a *default* UI to go along with a *default* install profile, which has hooks for swapping out and mangling however, is probably an achievable goal.
    [chx] webchick: and then you have “beginner’s Drupal” with a nice and shiny UI and “advanced’s Drupal” which is what the hard core site builder Drupal consultants use and then who the hell is going to code beginner’s Drupal interface?


    [lyricnz] As an outsider (!), it seems like most people are kind of dissappointed with how things are going over at d7ux.org, and just ignoring it, hoping it’ll go away, or not be too terrible [...] finding it hard to form logical objects, other than “uuugh”

  36. 36 ben_ said at 8:30 am on April 13th, 2009:

    @Inline Editing: I know, that all of Drupal’s Modules and Architecture make it hard to allow complete Inline Editing, BUT, compared to most other WCMSes, Drupal IS almost already there:

    1. The current concept of the local tasks, inside the frontend, which only appear if you have the permissions to use them, are close to what the d7ux team comes up with.

    2. Usually the node-creation/editing form appears in the same layout at the same place, where the ready-rendered Node appears. You just have a few more fieldsets and buttons than the d7ux-team right now comes up with.

  37. 37 disambiguity » D7UX Update: Initial Concepts, Design Principles and a question for you said at 10:52 am on April 13th, 2009:

    [...] concepts for the interface model for Drupal 7. You can see an overview in the video above and we describe it a little over here. If you haven’t already given us your feedback I’d be really interested to hear what [...]

  38. 38 Per André Rønsen said at 2:13 pm on April 13th, 2009:

    Great work!

    I love the simple header… I would like to see something like a custimizable Administration Menu (module) + a custimizable few icons.

    Inline editing looks good. It would be nice to switch overlay on/off; I like navigating with urls/backspace, too.

    The edit screen for the individual blocks looks good; it’s nice if I don’t need to go back to the main block edit page to do the block placement.
    Panels extended looks good, too :)

  39. 39 Ronald said at 2:32 pm on April 13th, 2009:

    re @chx re:irc chat – Given the repeated calls to participate it does seem that quite a few people may well simply be ignoring this…

    I think what may help people engage more is an understanding of how is this exactly going to move forward. For example, if we all say “yeah – direct manipulation kicks ass” – then how is that actually, really going to be implemented in Drupal – i.e. who codes? The Drupal community strike me as a practical bunch and people will be doing calculations on the basis of “is this worth my time – will anything I say actually have an impact/ever be implemented?”

    I know there is an earlier post that describes where we are and where we are heading but the coding part is a rather vague. A line at the top that seems to indicate that coding has already started. Boulton & co are meant to come up with the great ideas/design (prototype/ library of interactions) but who implements? For that matter, what is a prototype – is it a full blow implementation in Drupal 7 or just a specification that then needs to be implemented? Will there be sprints to move from prototype to something that is part of Drupal? Is there someone already responsible to handle that part?

    Perhaps if there is a better understanding of what resources are already committed to achieving things then people will feel it makes more sense for them to devote their time upfront to comment on what should be implemented (as a function of what resources are available).

    Don’t get me wrong I am all for this process but with more of the questions above answered more people might join in.

  40. 40 Michael Favia said at 9:46 pm on April 13th, 2009:

    Following a 2 hour conversation with Webchick last night (aout getting involved with proper feedback for you two) I started a response to this initial concept and direction.
    It got a little long for a comment so I posted it on my own site. I also have a few suggestions for better engaging those of use that are developers and ux folks if that is your goal but I’ll save those for another post. I hope the following is taken in the spirit of constructive criticism and mutual respect that it was intended.


  41. 41 Nathan Haug said at 11:10 pm on April 13th, 2009:

    The three main UI concepts in terms of implementation:

    Menu bar: No problem

    Popups: Difficult but at least we have a foundation for implementing that in the works already (see Tao Starbow’s Popbox patch and Popups API

    Inline editing: Extremely difficult. It’s not that the JavaScript is difficult or that we don’t have the technical knowledge. It just happens that inline editing (as you’ve described it) isn’t compatible with the way Drupal assembles the content on the page. When using CCK, you might have dozens of fields that include things like select lists, image uploads for different purposes, grouped fields, addresses, etc. The way the data is entered can (and usually is) be drastically different from the way it is displayed. Worse yet, often times fields don’t even have an effect on the display at all. Say taxonomy fields or the menu settings. These can affect where the content is located on the site, but might not be displayed at all to the end user. In addition to this problem of multiple fields all affecting the display, Chx also posted an extensive thread in #33 on why Drupal’s filtering makes inline editing of just a single body field difficult also.

  42. 42 mac said at 11:23 pm on April 13th, 2009:

    Kudos to chx and all the the other core coders, and much respect for their input as experienced insiders.

    I agree to a large extent with the point you put forward: I myself (comment #19) said something similar, although with different words. There is however something in the general tone of your feedback that I found unpleasant and particularly the quotation of a chat that happened between other people, in another context, which I find out of place here. If you have something to say… just say it. If it is worth being listened to, it will, if it is not, even the fact Alan Turing in person might have thought alike, won’t change a poor feedback into a good one.

    Anyhow… the point I would like to make here is not about that post in particular. But more in general:

    1. Drupal is – from a UX point of view – one of the worst CMS around . This is *obvious* to any newcomer, but since we tend to spend on drupal so much of our energies, and time, we all stop noticing it. Some refuses to even acknowledge it. Don’t get me wrong…

    2. …Drupal is an awesome tool for the coders and designers who want to quickly deploy a solid, extensible web application / CMS, yet…

    3. …Drupal is not so much awesome for the end user with limited experience who want to set up his or her own website.

    4. We – as a community of coders/designers could well not care about point #3, but this would be a strategical mistake. Wider adoption = wider ecosystem = more diversification, more resources, more ideas, better feedback, new perspectives and – not secondary for those who make a living out of drupal – more business opportunities. Even in the GNU/Linux arena (where answers like “go and get it done by yourself, I use the CLI” were once very common in response to questions/request on usability) the wind has changed since many years now.

    5. There is a well known saying that goes something like “no problem has been solved using the same mindset that generated it”. This perfectly apply to the UX in drupal. The drupal UX has been “designed” (but somebody might say “put together”) by coders, for coders. I would not expect the same people (unless they would radically change ideas) to come up with something really different, yet…

    6. …some of these people has been smart and courageous enough to take a step back and ask somebody else, somebody with complementary skills and knowledge, to give a fresh look to their baby, give feedback and feed ideas…

    7. …Therefore I find counter-productive *at this early stage* to somehow try to counter the points arisen by the D7UX team by saying “you don’t know what we know // you are making uninformed choices // who the hell is going to code that”… What this exercise is all about, is getting a fresh look and fresh ideas for D7, after all, not a reimplementation of what already there. That said…

    8. …I do fully agree that it is unrealistic to propose *for implementation* as UI/UX something that is miles apart from the underlying architecture but I do not necessarily think that this is bad in an early prototyping phase. Look at the car industry, look at fashion, look at aerospace… their prototypes are often unfit for implementation, but it is from their prototypes that most of the ideas going to production come from.

    All of above to say… give the D7UX team some slack. THEIR slack is OUR opportunity to improve an already awesome piece of software.

    Cheers! :)

  43. 43 Tao Starbow said at 11:37 pm on April 13th, 2009:

    I have been playing around with a simple inline/overlay hybrid. The idea is to allow links on the node view page that popup a single form element (or set of form elements) from the node edit form. This has the advantage of being much more approachable to a new user that the entire, often overwhelming, node edit form, and it is much easier to do that true inline editing.

  44. 44 webchick said at 11:52 pm on April 13th, 2009:

    I both agree and disagree with mac’s #42. (Incidentally, mac, your quote at #19 about the restaurants is like my favourite quote ever! :D)

    We are definitely in conceptual, “big thinking” mode here, and the sky is, quite literally, the limit at the current moment. We’re only dealing with paper prototypes at this stage, so there is definitely nothing set in stone, and everything’s very fluid. And it’s critically important to throw these big ideas at the wall right now, and see what sticks.

    However, I *strongly* disagree that now is an inappropriate time for developers in the Drupal community to not only both be following and engaged with the work Mark and Leisa are doing, but actively participating in this discussion which, to many, means speaking to the viability of implementation in the “real world.” If anything, I think during the paper prototyping phase is exactly the correct time to bring up some theoretical implementation challenges, because paper can easily be ripped up and made anew if an approach genuinely won’t work. It gets much harder to do this further down the line once we get into Photoshop mocks or, heaven forbid, HTML.

    I understand and agree with your sentiment that in order for “big, out of the box thinking” to work, it needs to be given free reign to do so, outside of these real world constraints, at least for now. But I read some sentiment in your reply that could be construed as “developers, go buzz off and let the /real/ usability experts work. we’ll come and get you when we have stuff for you to build for us.” And I think that sort of attitude would be the very biggest strategical mistake of all, as it starts to pit one very important part of our community against another very important part of our community.

    Drupal is so great because of the diversity within the community, and for this project to be a success, the full range of our cacophony of opinions needs to be heard, respected, and celebrated. If we get the developers, site builders, end users, and usability experts on board with the same plan, then Drupal 7 will have so much win it might just take over the planet. But if we draw lines around “camps” or “classes” of participants, we risk alienating people. And this project isn’t going anywhere with alienated developers.

  45. 45 webchick said at 12:03 am on April 14th, 2009:

    Now, on a completely different note, here’s a cross-post of a video showing the work that Lullabot’s been doing in this area for the past year:


    You’ll notice quite a bit of overlap with the concepts Mark and Leisa are floating around here (which is very interesting/validating to see! :D). We did actually manage to build a lot of this stuff with Drupal 6 and some creative use of contributed modules, so it can be done. Whether some of these design decisions make sense as part of Drupal core is something that requires a lot of discussion/hammering out; a lot of the work we did on Buzzr was *removing* options and making best-guess decisions on users’ behalf and obviously you can’t get away with that kind of shenanigans on a framework that should be able to build everything from a brochure-ware site for a small business to a crazy e-commerce-enabled social networking site, to a slimmed down web service designed to search Amazon products.

    One thing that’s different about the approach taken by Bond is that “Edit” mode (what we call “Layout” mode) lets you edit both the layout *and* the content on the page as well. Rather than inline editing, we go with a consistent edit “button” kind of thing found on every element in the page, from the site title, to a sidebar block to the content itself. This maps more closely to what Drupal users are currently doing with things like the Zen theme which pop up little “edit”/”configure” links over blocks without having to enable a separate mode of some kind. Anyway, just some food for thought.

    I’m still left a bit confused about the thing exposed at the end there, though. Is the idea a drag-and-drop site map ala MS FrontPage, and then by clicking on a page within the site map you can control the layout of columns/rows? The biggest question mark for me on that is what do you do about block visibility? Currently, we let blocks be visible only on certain pages, on all pages but certain pages, or get fancy with some PHP snippets. We’ll want to make whatever system we use for page layout supports this kind of flexibility.

  46. 46 mac said at 12:37 am on April 14th, 2009:


    I do *fully* agree with your post. :)

    Your reaction made me aware I probably gave the wrong impression with my previous comment: I am totally in, for having all the ‘classes’ of *participants* to… *participate!*, and I couldn’t see the value of a redesign that would not take into consideration the point of view of core developers and drupal gurus. :)

    What I disliked was the tone of the post I commented on, not its content.

    It felt – at least for me – somehow diminishing the effort put by the D7UX team in keeping open this very same process… Quoting a self-proclaimed outsider’s impression of “people’ disappointment, will to ignore D7UX an hope it will disappear” felt very much like a frontal assault on this participatory process.

    What about simply saying: “as a core developer I expected this process to be very different from how it is unfolding, and I feel frustrated by that and would like the discussion and the proposals to be more anchored to Drupal’s architecture”?

    Besides (and this was probably the most important bit for me) I wanted to make the point that a better UX is *strategically* important for Drupal, even if that means a lot of work, with less energies to dedicate to the implementation of exciting new functionalities.

    Other than that, I pretty much agree with what stated in that post. :)

    Long live Drupal, its core developers, the documenters and – above all – its very diversified “long tail”! :)

  47. 47 Waldo said at 5:56 am on April 14th, 2009:



    Believe it or not I think the “features instead of modules” UI enhancement is the best thing… and you saved it for last!

    Is there any chance that it can use a central repository with signed modules to automatically list/install the “features” (a la Google’s Android Market or APT?)? Think of the ease-of-use to add “features” if you could find them easily via the listing, check the box to download/install the files, and then set your permissions, etc…

    Obviously there are massive security implications here– it would be downloading & installing executable code– but just as apt-get relies on the trustworthiness of the repository managers, the same would apply. It would also make module updates transparent and automatic. All via cron & signed keys.

    Just a thought. VERY VERY nice work. This is the future.


    PS– tried posting this on lullabot, but for some reason it wouldn’t “take”.

  48. 48 Donald said at 9:14 am on April 14th, 2009:

    Thats a great video. All these were being said in drupal forums and groups for so many years. Excellent sum-up. Great video quality. Now it will be great if the core Drupal team couples with this team as things are already there, instead of re-inventing wheel!!!

  49. 49 Jeremy Yuille said at 11:19 am on April 14th, 2009:

    nice work Leisa and Mark! very encouraging.
    LOVE the direct manipulation thingy.. very exciting!!!

  50. 50 Dennis Robinson said at 12:50 pm on April 14th, 2009:

    Apologies for cross-commenting, I meant to put this comment in initial concept/design….not process:
    I’ve been working on CMS’ for some time now, including Drupal.

    One concept I ran into during the build of a bespoke corporate CMS I really liked where there were a number of editors…is the idea that each editor had a personal work space. They called it ‘page builder’. However, the interesting thing about it was that it had a ‘clipboard’ of work-in-progress and ‘libraries’ of re-usable site-wide pre-fab items (that may include content or be varied) that could be access quickly when you were creating pages. There was also permission and workflow, as you would expect.

    I find a lot of the time when I’m configuring Drupal I have to flip back and forth between key ‘design’ modules (e.g. views, blocks, panes…etc) and the relationship between these elements isn’t obvious. Finally, I need to create the specific content type that an editor can choose from a long list when they want to create something.

    It would be nice to be able to access all the things that I need to build a ‘page’ or ‘view’ from one palette, giving editors enough tools to be able to create, design and edit (what they are allowed to) in the same place.

  51. 51 Nikolai said at 12:59 pm on April 14th, 2009:

    Hi there.

    I launched my new site colorfreak.com in Drupal, hoping that I could add photo galleries, forums, member’s areas, user blogs, polls, surverys and all sorts of cool things and build a whole site instead of just a blog.

    Sadly, I got frustrated very quickly with the theming framework (I wanted to modify my theme a little), how many thousands of modules I needed just to do some simple stuff (I actually find that PATHETIC), no proper working WYSWYG, extremely difficult to add images and media in an efficient manner, some needed modules being available only for Drupal 5, no easy way to properly administer comments like in WordPress, need for FTP or manual uploading when I want to install modules, no good commercial themes available…

    I think I could go on quite a bit. The point is, that even though I wanted a really cool Drupal site with tons of features, I felt I was forced to move to WordPress (which I did). No I’m pretty restricted in what I can do with my site, but at least I can do those things properly.

    To me it feels like Drupal can do 1000 things, but it sucks at all of them. I mean, the forums module, besides being extremely basic and worthless for a site that requires proper forums, have not been updates much in years. WordPress can (mostly) only blog, but at least it does it well. I have comments, trackbacks, an easy-to-use theming engine, I can easily add media to content, and so on.

    What really irritates me is that the super-geek-hardcore Drupal crowd refuses to accept that Drupal is broken and that it need fixing.

    On a positive note, I really like what you’re doing to Drupal and I hope that someday I can use it again. I’m looking forward to that day since I actually really need some of Drupal’s advanced features.

    I like the popup-inline thingies and I think they will speed up website management A LOT.

    The header thing is also a good idea and you could maybe have menu dropiing down from there for more stuff…

    Thank you for the work you’re doing and good luck.

    PS: Are there any plans for a Drupal 7 release?

  52. 52 mac said at 2:10 pm on April 14th, 2009:


    I can understand your frustration and – as a drupal (self-proclaimed) evangelist – I wish I could tell you that you are wrong, that all you wish to accomplish is just one click away…

    …but this is not the case.

    On the other hand, I believe your post isn’t always fair, in that you seem to refer to “drupal” (the framework) and to the “drupal user experience” interchangeably, while the two are very different things.

    So, when you say that “the super-geek-hardcore Drupal crowd refuses to accept that Drupal is broken”, I disagree with you. Drupal is probably the best, more flexible and elegantly designed CMS around. It can be improved – for sure – but it is in no way broken.

    What it is broken and in need of some love is the user experience, but this is another story, and the very existence of this space proves that the need has been recognised (at least by some) and work is being done.

    Comparing WordPress with Drupal is only partly fair. WP is an excellent piece of software too, with many functionalities in common with Drupal, but the two plays in two different categories: WP can blog. Drupal can blog ***too***, but it is not a blog-centric platform in any way.

    That said, WP offer a simple, very nice user experience and there is no reason for which the Drupal community should not look at it as a source of inspiration.

    Sure, there are some features which Drupal misses badly (like a native WYSIWYG editor with image handling) but since Drupal can do 1000 things (most of them very well, actually) making easier for a newcomer to do one of them cannot impair the possibility for the other 999 to be done effectively, or for an advanced user to do the very same one in a different way.

    Finally, I feel that is a mistake to perceive the D7UX team as doing something “to Drupal”… since drupal is “community plumbing”, the only way one can impact on it is by doing things “together with the Drupal community”. :)

    All the best, Mac.

    PS: D7 will be out when the number of critical issues will be zero. I suggest you search Dries’ blog (http://buytaert.net/) for more info about the release philosophy currently in use for Drupal lifecycle.

  53. 53 neochief said at 9:25 pm on April 14th, 2009:

    I should agree with Nicolai (#51). There are tons of active bugs in issue queues for Drupal 6 right now. It’s not just about core. It is more about highly used contrib modules. I have 7 projects with Drupal, and have to maintain dozen of patches for all of them while patches are being stuck in issue queues with no progress at all from maintainers side.

    Yeah, I know this is less touching the current topic, but it’s a loud soul cry of most part Drupal-sites maintainers—bad contrib quality, not the core.

  54. 54 Boris Mann said at 2:25 pm on April 16th, 2009:

    @mac: “What I disliked was the tone of the post I commented on, not its content.”

    Please try and remember that large numbers of our community use English as a second language, so the tone you hear in your head is not always the tone that is intended :P

    I happen to be bilingual in German – most German phrases when literally translated actually come across as commands in English — i.e. “You must do this”, rather than the wishy washy American “You should probably do this”.

    Just something to keep in mind.

    That being said, I actually agree with and have already raised the flag several times on UX for all of Drupal vs. UX for the default out of the box install profile.

    There are literally only a handful of people that have EVER worked on the core install profile and out of the box experience. If we don’t start working on it now, there is no way we will get to the level of polish needed.

    I’ll leave thinking on framework vs. out of the box experience as a dangling thought.

  55. 55 Drupal 7 User Experience Project » Blog Archive » Current Activities - What you can do NOW! said at 9:31 am on April 17th, 2009:

    [...] Initial Concepts for your review: take a look at the direction we’re headed in and give us your feedback [...]

  56. 56 Mike Gifford said at 2:29 pm on April 21st, 2009:

    Wanted to quickly follow up here with concerns about a move to heavy AJAX adoption within D7. Accessibility issues will get more complicated and any implementation needs to be based on Progressive Enhancement.

  57. 57 Dave Jones said at 1:45 am on April 23rd, 2009:

    I don’t understand how you can consider “drupal” (the framework) and the “drupal user experience” to be quintessentially different.

    To start with, although Drupal exposes an API it cannot accurately be defined as a ‘framework’. Drupal’s own website describes it as “a free software package that allows an individual or a community of users to easily publish, manage and organize a wide variety of content on a website.” That certainly doesn’t sound like the description of a framework to me, and by that definition I would contest that it IS broken.

    Even if there was a seperate framework and “drupal user experience” it wouldn’t matter since it is impossible to benefit from one without the other – to have no “user experience” is to have no users.

    Whilst I concede that there is much elegance in the code and structure of Drupal that, in and of itself, is not enough.

    As it stands Drupal is something of a “curate’s egg.” I’m sure you will try to convince me that “part’s of it are excellent”, but for me it remains inedible.

  58. 58 Anonymous for now said at 10:26 am on April 23rd, 2009:

    I think Mark and Leisa need to get their hands dirty and build sites with Drupal. Sites such as digg clones, news feeds and all to really understand how Drupal works.

    Everything so far seems to be geared towards the content writer/editor/moderator experience rather than the site builder/developer experience.

    The admin menu is a nice addition and can help the site builder/developer. It would be great if the header/admin bar was also available to registered site users in a more simple form with shortcuts to content entry pages and it allowed site builders to add tips of the day or advertising messages.

  59. 59 mac said at 10:57 am on April 23rd, 2009:

    Hi Dave,

    the risk of this exchange is to become too much about words and too little about the reality of things.

    However I tried to explain myself a bit more:

    I called drupal a “framework” because a lot of developers tend to develop the front-end AND the back-end of their system. [There is some excellent video linked from comments to this website showeing how developers created nice interfaces for site administrators (their clients)].

    It is very unlikely that a dev would deliver a project without a good reconfiguration of permissions, UI, menus, graphic etc… of the standard Drupal interface.

    Although I understand what you mean, I disagree from the statement: “Even if there was a seperate framework and “drupal user experience” it wouldn’t matter since it is impossible to benefit from one without the other – to have no “user experience” is to have no users.”

    If you look at drupal as a blogging platform (see WP) you are probably right, but if you look at it from the perspective of a framework, then the two things are definitively separated, because frameworks are conceived for developers to design webapps providing a nice UX to the final user, which is exactly what many devs around are doing with Drupal.

    Now, I am totally in favour of making Drupal more accessible to final user for the reasons I explained in other posts on this site… what I think it is wrong, is to approach the problem by evaluating Drupal overall value from the smoothness of it’s user experience.

    The real asset of Drupal is its architecture geared towards extensibility and modularity: a nice end-user-experience is something more. Very much welcome but not essential (see how other successful framworks are, for example!)

    Additionally, Drupal adoption is strongly on the rise: I think this is the most accurate data available to say that Drupal is anything but broken, and that the lack of a smooth UX de-motivates potential adopters far less than drupal flexibility motivates them! :)

  60. 60 Dave Jones said at 10:58 am on April 23rd, 2009:

    Well if you want a laugh there are a few videos of Leisa and Mark getting down and dirty with Drupal for the very first time. http://bit.ly/yn6OR

    Although it can be funny to watch them walking right into some of the pitfalls, these videos serve as a very good illustration of what is wrong with Drupal UI at the moment.

    One of the issues is that it is often difficult for “Drupal people” to see Drupal through the eyes of the uninitiated. When you approach Drupal as someone who knows a bit about online content publishing systems, and has maybe used one or two in the past, but knows nothing about Drupal, or how Drupal works (and how it expects you to work) the result is often frustration and simply not knowing where to go next.

    I think some of the stuff in what Leisa and Mark call “Information Architecture” probably incorporates the site building ‘stuff’ that you’re looking for. IA is a pretty bad name for it though. But then as a Drupal user you should be used to being faced with oblique names for straightforward concepts ;)

  61. 61 ben_ said at 11:15 am on April 23rd, 2009:

    If you are a builder/developer and you evaluate Drupal as a possible System for your Site, than you’re certainly fine with all these abstract Ideas and bulky clickpaths Drupal has.

    But if you’re a writer/editor/moderator then Drupal current UX will most certainly let you choose another System like WordPress. And it’s those Classes of users, who would benefit most from an improved UX.

  62. 62 Dave Jones said at 12:00 pm on April 23rd, 2009:

    You have certainly given me something to think about. You have got a very interesting perspective of what Drupal is and I’d be interested to know whether other people share it.

    From my point of view a framework must be three things. It must be abstract, it must provide a well defined API and it must involve some form of inversion of control. A framework helps a developer write great software, but it provides no benefit to the end user in and of itself.

    I would agree with you that if you are developing a completely custom management back end for your users, so they don’t have to use any of Drupal’s built-in administration as a means of adding and editing content, managing menus, adding blocks, etc. then perhaps you are using Drupal as a framework, and in this case the Drupal UI experience is mostly irrelevant. I would probably see this as largely a waste of time since, IMO there are better, more productive frameworks out there, but that is perhaps a matter of personal taste.

    What I would have to question though, is whether that usage can be considered ‘the norm’. As I mentioned earlier, Drupal styles itself as “a free software package that allows an individual or a community of users to easily publish, manage and organize a wide variety of content on a website.” This, to me, strongly suggests that Drupal’s target audience is people who are looking for a content management system. Compare that with CodeIgniter’s description, “CodeIgniter is an open source Web Application Framework that helps you write kick-ass PHP programs.” It is clear from this statement that the target audience is developers, and that the framework provides no concrete solution to end users.

    The problem is that as an individual looking for an easy way to manage content on a website I would suggest that Drupal is infact broken. Your position is that it’s not broken I simply need to hire myself a developer to create a usable interface for me. That is simply not a tenable position. Either Drupal needs to stop promising that it “allows an individual or a community of users to easily publish, manage and organize…” and start calling itself a framework with a target audience of developers, or it needs fixing.

  63. 63 eric said at 8:25 pm on May 6th, 2009:

    Simmering it for a very, very, very long while.

    In anything like the form represented by Panels 2 or Panels 3, it’s exactly, precisely the wrong direction: More or less the opposite of the direction represented here, toward greater complexity and abstruseness, and away from simplicity.

  64. 64 eric said at 8:40 pm on May 6th, 2009:

    2: Inline editing, particularly w.r.t. where you have to click. I realized when someone upthread mentioned Administration Menu module that I was a little unclear on exactly where the toolbar is. If it’s pinned to the top of the window (as Administration Menu is pinned to the side of the window), you wouldn’t have to scroll up.

    3: The real problem with page hierarchy is that it has fundamental impacts that have to be hashed out. Is it driven by the menu system, or by taxonomy? Does it imply that all nodes become like book pages? Mind you, I think it’s a great idea, but might be too ambitious for D7.

    All that having been said: Putting Panels in core in any way would scare the hell out of me.

    Panels has been a nightmare for me, a huge time sink, especially Panels 3. Maybe you understand it — I don’t, and I haven’t found a high level explanation anywhere of how it’s supposed to work. I get the vague sense that it’s meant to replace theming. Or not. I don’t know — and I don’t see that I have any way of knowing, because Merlin hasn’t taken the time to spell out his vision anywhere but places I don’t know about and can’t find out about.

  65. 65 eric said at 8:54 pm on May 6th, 2009:

    Everything so far seems to be geared towards the content writer/editor/moderator experience rather than the site builder/developer experience.

    Speaking as a site builder, the writer/editor/moderator experience is what matters to me: They are my users.

    If the UX is optimised for me, it’s a bit like cars being built to suit engineers instead of drivers.

  66. 66 eric said at 9:11 pm on May 6th, 2009:

    My impressions:

    I’m not sure where the “header” lives. Is it pinned to the top of the window, like admin_menu is pinned to the side? Not injected into the theme? If so, I like it; if not, I think it’s probably a dead loss, because it won’t integrate into an awful lot of themes. (One of the first things I do with a theme when I’m hacking it is turn the tabs into buttons so they don’t look so bloody confusing when they line-wrap.)

    W.r.t. “overlays”: There’s a common prejudice in UX circles against modal dialogs. I’ve never understood it. They seem fine to me for some things, and what I see here seems like that kind of thing. But chx (I think) has a point that they’re not really suited for everything that happens in the system. It’s a web app, not a desktop app, and we’re accustomed to interacting with it in a different way. Keep the modal stuff relevant to the page it’s on top of.

    W.r.t. inline editing: Two years ago I tried out a module that added inline editing to Drupal 4.x. Or was I smoking crack and imagining it? It seemed to work reasonably well, but it wasn’t going to work for our users for some stability reasons, if I recall.

    I totally get why inline editing wouldn’t work if done simplistically, but Tao Starbow’s idea of combining inline with overlays could address that quite nicely, and it seems to me I’ve heard other people talking about similar ideas.

    As someone who has to train end users to maintain the site and add content to it, I can tell you that the more “inline” I make it — and the more I stress the ways that it approximates being “inline” — the easier it is for people to understand how to use it.

    W.r.t. the “DMT”: I would love to see something simple in this regard. Drupal just doesn’t really have any good options for global information architecture or variant page layout right now. My apologies to MerlinOfChaos — I know Panels is a hugely complex endeavor and there are some things that Panels 2 does that are impressive and clearly intensely useful (like taking arguments for panels as parts of the URL). But that complexity works against it, and I just don’t see that improving (in fact, see the situation degrading ) in Panels 3.

    I actually think something really mundane is liable to bite any page layout component, and that’s stylesheets. One of the big problems I have with Panels is in trying to realize designers’ designs as Panels layouts. I find that there are so many nested containers that I have to baseline reset everythng to zero and build up from there to get the positioning I need. I don’t believe that drag and drop will ever work for realizing designs made by others (which, let’s face it, is what most web geeks in agency settings, like me, have to do) — i just don’t believe it, my experience is so strongly to the contrary on that matter. I will always have to be able to stipulate the position, padding, margins, borders, etc. in the stylesheet, and that’s non-trivially difficult right now.

  67. 67 Geoff Campos said at 8:36 pm on May 13th, 2009:

    Just some rash opinions – I haven’t read all the comments in this thread and have only just caught wind of this project.

    Header: To me, this is a customisable, credentials-sensitive toolbar similar to that found in MS Word. +1 from me – it’s a creative’s palette.

    Overlay window: Rather than ‘float’ something over the web page, why not lead the editor to a form with a facsimile of the current page slung underneath? This would avoid the layering (and the javascript) and preserve the user’s access to the ‘real’ page thus enabling quick review (and there’s nothing wrong with scrolling).

    Inline editing: Whenever I’ve encountered customers using Plone 3, they have all switched this feature off – they feel it’s too dangerous – too easy to accidentally make changes (even if it’s not). They never take issue with switching the application into ‘edit mode’.

    Love the videos by the way, makes the whole venture very engaging.

  68. 68 ultrajet said at 1:16 am on May 20th, 2009:

    does that mean you are able to change css and templates like resizing content’s size directly without going to codes? cool!

  69. 69 Terry Sutton said at 1:26 pm on May 26th, 2009:

    I do have to somewhat agree with this. From what I’ve seen in the past few years, the best Drupal sites are not blogs and forums – they’re major content sites. I’m thinking here about the Chicago Art site, HarvardScience, everything from Dev. Seed, etc.

    Having said that, there’s a reason why people choose WordPress to run their blogs. Sure, Drupal can do all sorts of neat things, but if you just want a blog, WP is an absolute joy to look at and use. I think with some of the proposed improvements in ux and with a concerted sales effort, Drupal could take over the blog market too.

    As for the rest of the thread:

    Major Yay for on-screen content editing. Being able to read a piece of content and edit it on the same screen (maybe via wordpress-like lightbox popup) would be grand. Note, this is on-screen editing, not in-line. I too suspect that in-line editing might well be dangerous.

    Having a customizable Header bar would be exceptional. If you could create bars that would be even better. I could create an editor bar for editors, an admin bar for admins, etc…

  70. 70 Geoff Campos said at 8:41 am on May 27th, 2009:

    ‘If you could create bars that would be even better. I could create an editor bar for editors, an admin bar for admins, etc…’

    That sounds like a great idea – a function where the admin can ‘build’ the toolbar for specific roles – this could also grant privileges at the same time.

  71. 71 G Delwiche said at 3:38 pm on May 28th, 2009:

    Hi Everybody,

    Respect for all the energy who is floating here :-),
    I discover Drupal recently, and there is one thing I pray to see in the next version, we speak here about the way to modify more efficiently our content, more efficently how to admin our admin panel but If I read cleary, we forgot something essential.
    With the constant upgrade of Drupal we constantly also generate for the non-developper a real stress, am I going to loose my beautifull website with this new upgrade ? When you seen the number of posts on that subject you realise that this process is a real pain in the…
    I mad a dream… :-) of a plug in or a functunality who could automaticlly do all that heavy stuff for you, just click… “Yes I want to sleep in that seven heaven too” (a little bit like they do that for the last WP version)

    I hope you will excuse my intrusion and my pore english
    God bless you all guys :-)

  72. 72 Phillip said at 6:25 pm on June 1st, 2009:

    3) “In line (inline) editing” – edit in place – what ever you want to call it. This would be an awesome feature.

    Jeditable seems like a good starting place since it integrates with jQuery.


  73. 73 Jeremy Wilkins said at 1:24 am on June 4th, 2009:

    The best “inline” editor I’ve encountered is the Campaign Monitor editor:

    It is a joy to use, circumvents a lot of nasty scripting problems, and can easily enforce presentation consistency.

Ein blauer Saphir, der dunkel schimmert. | roaster coffee | Assisted Reputation SEO