6.0 Structure

updated 7 June
Experience Architecture
Proposed Experience Architecture, large image here
updated 5 June

Walkthrough of an updated approach for the Site Builder.

Description: Structure will contain two main sections, a ‘Site Builder’ tool that will make creation of a reasonably sophisticated website relatively easy for non-technical people, and the Taxonomy interface.

Current thinking/roadmap:

  • The Site Builder is intended to help people new to Drupal make a site using Drupal in less than 30mins. Not necessarily the final site they want to launch with but to ‘make something’ successfully
  • The site builder is essentially a ‘magic user experience layer’ over the toolset that Drupal developers currently use to build a Drupal site.
  • The rapid site building is accomplished through the design and inclusion of a collection of sample sites, including the content types, pages and functionality most likely to be required. Novice users can choose one of these and do minimal editing to get to a finished site. Advanced users will create their site from scratch
  • Blocks, Views, Content Types are created using this interface, as the user defines the content to be shown on each page.
  • The site builder will support a range of levels of expertise – starting with the novice Drupal user and right along the learning curve to expertise

Aggregated Feed (Pipe) of Related Discussions

Please feel free to add your thoughts as comments below or if you’d rather publish them elsewhere you can have them the pipe by using this tag #d7ux_6_0

go back to Project Framework to view all project components

48 thoughts on “6.0 Structure”

  1. No such thing as a page today. Closest analog we have today is:
    * URL paths (i.e. about or news – which underneath is a single piece of content plus regions or in the case of the latter, is a list / filter of content)
    * the contrib concept of panels
    * the contrib concept of a view

    This MIGHT be driven directly by menu. Think of another screen that is more like a sitemap. Add menu items with labels, and then wire up content to it.

    So, an “About” entry might exist, but not be wired to content yet. Click to add page/panel/view whatever although that may be hard for people to grasp.

  2. I’m reading this as page template (page*.tpl.php) editor and manager! With the left hand portion as collection of page templates that build up the site templates.

    This will be good, but we need to define the ‘components’ that can be dropped onto the page so that we can have those components themed.

    The closest I can think of are
    – block & region
    – and panels ways of adding content

    1. one of the biggest challenges I think Drupal faces is trying to get past the implementation model, and see things wrt the experience a user has.

      Drupal’s got a really flexible implementation model, but in many ways it has solidified in the last few versions as things like OG and Views and start to move closer to core and the various templating systems start to coalesce

      caveat, I’m nowhere NEAR core: this is my perception as a ‘weekend warrior’ who’s lost a few too many weekends drupal wrangling for weekday projects 😉

  3. /me shudders. Glad to the the “This is not a DX tool” thing. I’m assuming I’d still be able to go to my familiar /admin holes 🙂 This would just be a layer on top?

    How closely will this need to be attached to the themes? My concern here is that it will complicate the process of theme building by having to be sure to accommodate it.

  4. I don’t really know the purpose of this section. You said that it’s not a DX tool, which means site builders won’t be using it, but it’s a tool for building sites…contradiction?

    Is the hope that you’ll start getting more weekend warrior DIY types downloading and installing Drupal on their own? In that case, I guess I’m game but it seems like it still goes against your “Design for the 80%” mentality.

    1. I guess it depends on how you’re defining ‘site builder’. I know lots of people (and I’ve interviewed lots of people) who are not developers but who want to be able to build website that do more stuff than a blog does. This is a tool for them. I think they’d be insulted to be called ‘weekend warrior DIY types’, in fact, I suspect they’re probably a fairly significant and growing audience. I think they’re probably the kind of people who might use Ning to set up a social network site but would rather have their own… does that make sense?

      1. Most interestingly, I think these are mostly the people who will try to us Drupal, and are a slightly less but still big part of those currently using Drupal.

        I am waiting for a video, that really explains this. But I think this the idea of Panels (which has been around for years) and just needs a better experience.

      2. without knowledge of blocks, views, content types, themes and anything else overly technical/scary.

        I’m very concerned about this phrase, especially when combined with the assumption that developers (and I think your definition of developers here is a lot wider than just coders and themers) will never want to use this interface.

        Completely hiding these concepts from new users, while expecting them to use the current interfaces if they want to do anything beyond the basics doesn’t really fix Drupal’s user experience – it just defers the pain to a later stage.

        With views and panels it’s possible to build very advanced sites without writing a single line of SQL or putting a single custom region into a theme – and lots of developers (whether the apparently broader definition used here or specifically coders and themers) do this all the time. This also means those same developers, when they run into the limits of what Views can provide often end up writing integration or API improvements to accomplish it – which means the next person can do the same thing without writing any code again. An interface for core should really be one which people building Drupal sites every day should want to use – if they don’t, then it’ll fall out of maintenance very, very quickly.

        An extra layer above content types and blocks is going to have a lot of arbitrary walls which users are quickly going to run up against – at which point they’ll have to go to the ‘old’ interfaces anyway – and without the basic knowledge which users currently acquire by stumbling around.

        I also very strongly disagree that content types and blocks are ‘overly technical and scary’. The interfaces aren’t great, the concepts aren’t always communicated well, and a lot could be done to improve them, what we absolutely shouldn’t do is leave them broken and put some fancy stuff on top.

        If we want people to select different layouts/templates for pages/sections of their sites and be able to drag and drop blocks within those – then that should be our blocks interface. Similarly a sitemap/hierarchical organisation tool should completely replace the menu and/or book interfaces. For Views, while simpleviews is interesting, I don’t think it’s a viable candidate for core – I’d rather see us provide lots and lots of default views which people can choose from instead – but then have the full views interface available when you want to edit them.

        1. Spoke to Bojhan about this briefly in irc, here’s a copy/paste of some of the discussion which might get my concerns over better than the above:

          Bojhan: what concerns me most is that all this stuff looks like it’s going to be a layer over the existing crap.
          which means we still have the existing crap in core.
          Well essentially it is, they are trying to hide the immediate more difficult concepts, which is good, however the problem is that they don’t solve the interactions surrounding these harder concept, rather they postpone experiencing them.
          Bojhan: read your header post, I think I agree on that. Seems like the way that ‘lots of modules and settings’ gets dealt with is we still dump them in the huge admin/settings dump
          And that’s potentially a lot more frustrating.
          catch: yup,
          its best to set low experiencines at the start 😀
          Yeah pretty much. If people give up then that’s too bad, but better than lying to people who stick around.
          Because that breeds resentment.
          Which is what I get the impressions provides Drupal with its long-term converts from Joomla and WordPress.
          we’r going to be wordpress/joomla?
          that is the impression you have?
          Bojhan: no, no.
          Bojhan: but joomla and wordpress (apparently) give you an easy ride the first day or so.
          Then when you want to do anything Drupal-ish you hit a big brick wall.
          So people leave Drupal because it’s ‘hard’, go over to joomla/wordpress, then come back absolutely hating them and figure things out with Drupal.
          If we make the initial Drupal experience /too/ easy, then I’m worried people will think that’s all there is, and have that same kind of trajectory.
          catch: So – thats important, and that was never the goal I think. We are trying to make concepts more clear.

        2. Spoke to Bojhan about this briefly in irc, here’s a copy/paste of some of the discussion which might get my concerns over better than the above:

          [catch] Bojhan: what concerns me most is that all this stuff looks like it’s going to be a layer over the existing crap.
          [Bojhan] read that one
          [catch] which means we still have the existing crap in core.
          [Bojhan] Well essentially it is, they are trying to hide the inmediate more difficult concepts, which is good, however the problem is that they don’t solve the interactions surrounding these harder concept, rather they postpone experiencing them.
          [catch] Bojhan: read your header post, I think I agree on that. Seems like the way that ‘lots of modules and settings’ gets dealt with is we still dump them in the huge admin/settings dump
          [catch] exactly.
          [catch] And that’s potentially a lot more frustrating.
          [Bojhan] catch: yup,
          [Bojhan] catch
          [Bojhan] its best to set low experiencines at the start 😀
          [catch] Yeah pretty much. If people give up then that’s too bad, but better than lying to people who stick around.
          [catch] Because that breeds resentment.
          [catch] Which is what I get the impression provides Drupal with its long-term converts from Joomla and WordPress.
          [Bojhan] Wait
          [Bojhan] we’re going to be wordpress/joomla?
          [Bojhan] that is the impression you have?
          [catch] Bojhan: no, no.
          [catch] Bojhan: but joomla and wordpress (apparently) give you an easy ride the first day or so.
          [catch] Then when you want to do anything Drupal-ish you hit a big brick wall.
          [catch] So people leave Drupal because it’s ‘hard’, go over to joomla/wordpress, then come back absolutely hating them and figure things out with Drupal.
          [catch] If we make the initial Drupal experience /too/ easy, then I’m worried people will think that’s all there is, and have that same kind of trajectory.
          [Bojhan] catch: So – thats important, and that was never the goal I think. We are trying to make concepts more clear.

  5. Hey when I saw you talking abou tthis in the video I started thinking that I’d seen it done in a way somewhere before…

    check out http://dub.washington.edu:2007/denim/
    It’s pretty old (in web terms) but may have creatively addressed some of the IxD crazyness you’ll face with a system like this..

    hope that helps.. and yes – as someone who’s not a developer, but has spent the time to get to grok drupal, this will definitely be designing for the 80%
    The ones who download drupal, install it.. and then go WTF!!?! and promptly head on over to Joomla or WP other things that have a very clear editing and architecture principles.

    1. aah, yes. I’d almost forgotten about Denim! Thanks for reminding me Jeremy, will have to go have another play with it now but from memory this is a similar kind of approach esp with the moving in and out from ‘sitemap-type’ view right down to, for example, block view.

      We’ve also been looking at the Yahoo Pipes interface by way of inspiration.

  6. I think I second catch. This might be similar to the decision of not putting the download button on the redesigned. d.o. Start page.

    It does not make sense to pretend that Drupal is totally easy. So this would mean, we got to think even deeper 🙁

    We need to build up an interface that slowly rises to the harder things, and probably need to rethink and restructure much more places than we thought.

    The only way to get a sustainable path would be to find a model every developer also finds as an improvement for himself.

    But personally I think, once we start to _also_ think more top-down and establish a culture that the UX gets in early in development and think – oh, how would a non-genius user see this – a different culture might establish. So we need a starting point.

    And as this something that appears to be overly simplyfied for long term drupal users might serve very well.

    All this will take much more time and energy than one thinks. But it has to be rooted deeply inside the _entire_ community, to be supported on a long term. Maybe we need ideas and a concept how to archieve this goal.

  7. 1. I didn’t completely follow your thinking regarding building navigation on sub-pages. It seemed limiting, but maybe I missed your point. Today, when you edit a node, you can choose the nodes point on the navigation tree (will the node be accessible via primary links, secondary links, or other). If you fail to choose a location, the node will be orphaned. Additionally, entire menu systems can be placed on a node, however this is done via the menu system vs. node itself.
    This would be more meaningful for me if you could A) alter the dynamically chosen menu path for the page itself (maybe I don’t want it to be a second menu) B), add many links off of the node itself.

    2. Blocks are a fundamental part of Drupal. I missed how you planned on working with them.

    3. I’m sure the two of you can overcome this, but if you’re on a page, and click to edit its view, then click to edit is content type filter, you’re potentially many levels of modal dialogs in, and hence it could become easy to get lost. Just pointing it out.

    4. If a page has many child pages, and you delete a parent, I assume all children go away? What if (as stated in item 1 above) 3 children each have their own menu blocks pointing to multiple places:

    Page A with links to d, e, f
    Page B with links to f, g, h
    Page C with links to h, i, j

    Then you delete the parent, will d-j all get orphaned? Deleted?

    5. This could be on or off topic, but since your building such a rich page builder, have you considered how Panels would or would not play with this model? How would you split your body into two columns? Would your designs allow such a feature, and if not, how would Panels integrate?

    6. I may have missed it, but I didn’t see how you might link your orphaned page outside of maybe drag and drop.

    7. While I like the concept of UX warning, seems ancillary at this point. I’d rather see you solve bigger issues.

    8. What happens when you have large sites. How do you navigate? Zoom? What happens when you zoom, do nodes just shrink and become illegible, or will each level of the zoom show less detail

    Last, while I know you’re excited about this concept, It personally scares me. I once built a similar org-chart like tool, but mine was based on people inside of a large corporate environment instead of pages of a CMS. Regardless, it shared many of the same traits. While it was an exciting, challenging project, every day produced a new issues. Thousands of man hours went into it. I worry detailing this tool will consume Mark and yourself, and if time runs out, the rest of your work will be jeopardized. How will one work with menus and blocks if this widget fails to be adopted or fails to get flushed out by contract end.

    1. 1. subnavigation still needs to be worked through a little more because we’re not generally creating nodes here, mostly creating content types, views, blocks, etc. The idea that I was presenting was that you would be able to create the navigation name if the page was ‘static’ or to set it to be created dynamically – what is shown is a fairly simplistic version of that though and as I think I said mid-stream, I have a feeling there’s a better way of doing it. There are lots of little pieces of this jigsaw that would really work well as ‘projects’ for the Usability team to take a look at and help us resolve and this is one of those!

      2. Sorry, I thought the block treatment was implied when I was talking through the way you assign content to a region, a block would be created at the same point at which you would create a content type, or a view etc. Agree that this is v important and that is one of the main reasons for being for this interface. There are a few scenarios I didn’t get to show in the prototype yet, will update with more examples soon.

      3. Agree orientation is important and something we’ll be considering carefully as the design comes together.

      4. If you’re deleting a parent (with children) you’ll be asked if you want to proceed and remove all of them (including ‘grandchildren’) – as per the deletion example given in the video, you’re not actually deleting nodes here, they still remain in the system, they become orphaned, as you suggest (note that the new Find Content interface should make this much less problematic). You can obviously move these children (and their children) elsewhere or remove them from the hierarchy before deleting a parent if you prefer.

      5. at this stage we’re thinking more about design than implementation, however we’re keen to take advice on the best way to implement this and what the design implications may be.

      6. Orphaned pages can be linked via drag and drop or via reordering in list view.

      7. Don’t worry, we won’t be spending too much time on UX warnings – there are a few that are relatively obvious and simple to include around recommended breadth and depth of navigation systems and maintaining consistency in navigation placement that we’d like to include. It’s a ‘nice to have’ tho’

      8. We have been considering a few zoom options, particularly something like the Google Maps type zoom. I think we want to do some more testing tho’ to see whether it is really necessary. This is not a tool that is idea for creating large scale and complex sites and it’s not intended for that – those sites will still be built mostly by developers and mostly using a ‘DX’ experience (that is v familiar to developers and can be gradually learned by people who may start with this interface and need to *gradually* learn more Drupal concepts in order to increase the scale and complexity of their site). Our initial investigations seemed to indicate that (pending visual design of course) we *may* not need a significant zoom tool. Also, bear in mind that the list view will handle sites with greater girth more easily too – this is a big part of the reason that view exists.

      I totally understand the concern about the work required to get this tool off the ground – this is why it is really important, I think, that we ringfence who it is for and what it is able to do – it is not intended to let everybody do absolutely everything in Drupal – just to let non-technical people get a reasonably sophisticated (that is, more than a blog) site off the ground without having to know everything there is to know about Drupal.

      I really feel that this is an incredibly important tool for making Drupal accessible to people who want to make stuff quickly before tackling a rather significant learning curve – and that by enabling their success quickly we can then move them onto a path to learn more about Drupal and perhaps move beyond this tool (or at least buy us time to make the tool more sophisticated, if that is the right way forward… that’s a whole other debate). I think this is a big part of the ‘game changing’ that Dries refers to in his latest d.o post…. so I think we should be a little worried, but also excited, and go for it…

      (and on that note I’m going to move onto Josh’s comments about how it can’t possibly work!)

      thanks for your detailed feedback Jeff – it’s really useful and appreciated.

      1. Apologies for sitting on the fence on this. I both like it and have some serious concerns about this tool.

        Why do I like it. The visual language is intuitive. At least easy to grasp. Personally I would probably mostly use the list view, but the hierarchical structure is fine, user experience wise.

        My concerns. The tool seem to be able to flip between several cross-cutting concerns – navigation/menu structure, content types, content. I’m afraid that the way it is presented it will lead to inconsistencies – future pages, with not yet existing types, orphans, discontinuity of the life of different ‘objects’ (pages, menu items, …)

        It is not a trivial problem to solve. What should come first the idea of a ‘page’ of some type which should slot into the structure or the page type? The programmer in me says the type should be written down first, while the idea is noted somewhere on the side, usually in my head. You seem to try to reverse it, but how would you validate the correctness? What guarantees can we provide that the use of the tool won’t leave a mess in the system?

        IMHO the problem is to both design the visual language both to reflect the underlying data and to provide the constraints and their checking to guarantee correctness of the result.

  8. Biggest problem: You’re creating pages, that in the most abstract way possible, can’t be created in Drupal without nodes.

    Let me revise that:

    Some pages are views (nodes on the homepage).
    Some pages are nodes (about us).
    Some pages are modules (Search page).

    So, I feel like I’m popping a balloon here, Views is a contributed module and isn’t there to begin with. The search module isn’t on by default.

    That leaves pages and a user-friendly message that says you may want to go download and install some “must have” modules to make use of this builder.

    And pages, unfortunately, don’t exist without nodes. So it seems like we’re creating placeholders for nodes. If we create a placeholder for a node, can we change the content type later? Can we replace the placeholder with a different node?

    I would feel better about this if someone from Acquia or webchick or chx or one of the main contrib authors would say, “oh yeah, that’s possible.”

    Perhaps Earl Miles (merlinofchaos) has the right kind of experience to say whether or not this is going down the right path.

    1. hey Josh

      I think it depends on who you are as to how abstract this approach is. For non-Drupallers, the process of making a ‘page’ can be incredibly difficult, mostly because it doesn’t map to any model they can think of of how a web page is made (don’t even get started on the idea that there are no such thing as ‘pages’!). So, for you and for Drupal it might be abstract, but for ‘outsiders’ it makes, more or less, a lot of sense.

      Our mission is to create a magic layer between how Drupal works and how people thinks – that’s the purpose of this interface.

      Yes, there are definitely issues that need to be addressed – lack of Views in core being one of them, let alone the usability of the View interface, – but that’s an issue for the usability of Drupal 7 for non-technical people that goes way beyond this solution and is more about what a ‘Jeremy’ might expect to come out of the box with a site building tool like Drupal.

      Acquia, including Dries, have had visibility on this for pretty much as long as we’ve had the idea. They’re nervous (as evidenced by Jeff’s comment above) but no one has yet told us that it can’t be done. We’ve also been dragging Tim Millwood (the Drupal developer who now works with Mark Boulton) into our discussions as we’ve been working more and more through the design of this tool and his input has really helped to guide what we’ve done, and he has a great knowledge of what Drupal and can’t do (which is not to say that Tim’s 100% comfortable with this either, but I think we’re gradually starting to bring him around… Tim?)

      I want to repeat what I said in response to Jeff above – this is not supposed to be a tool that everyone uses to do everything about building a site in Drupal. It doesn’t replace the way that developers currently build sites – if you want to continue doing it as you do it now, then that’s great and there will be *lots* of instances where that is the best and most efficient way to go about it (if you have a good understanding of the workings of Drupal) – all we want to do here is make a tool that makes it possible for someone without a lot of Drupal knowledge to build a site that is more than an ugly blog in an hour or so. I think that’s a goal we have to achieve for Drupal 7 if we want to call it properly awesome.

      1. Fancy that… I was falling victim to what so many of us do these days, I was worrying about the “how” instead of the “why.”

        I always tell my clients anything is possible, but not everything is affordable or doable within your time constraints.

        Maybe the “nervous” feeling everyone is getting is a healthy thing. I think a lot of the commercial CMSes are also feeling nervous, thinking they may be out of a job… Thank you for such a long and thoughtful response. It’s wonderful working with such a transparent and open team.


        1. Dries was just telling Mark & I the other day that he is pleased that we are terrified every morning when we sit down to work – he thinks it is a good thing, and so do I (although, I’m so taking a long, long holiday when this is done!).

          I think the nervous feeling *is* a good thing, it means we’re doing something that actually matters, I think.

          And thanks, it’s great working with you too 🙂

  9. @Leisa: “..this is not supposed to be a tool that everyone uses to do everything about building a site in Drupal. It doesn’t replace the way that developers currently build sites – if you want to continue doing it as you do it now, then that’s great and there will be *lots* of instances where that is the best and most efficient way to go about it”

    As I said above, this is what really concerns me about this entire approach.

    We used to re-order stuff with drop down weight fields (-10 10) until Drupal 6 where the drag and drop interface was introduced to core. No developers still use the ‘weight’ field, and a lot of developers have incorporated drag and drop into their own modules – re-using the code and interface components provided by core. It’s not the case that developers want to stick with the old and broken, they just want the new and shiny to work for them.

    Drag and drop is now central to a lot of core and contrib interfaces, and pretty much transparent to end users (going by usability testing at least) – for me would be the main win from d7ux – re-usable things which can be applied to contrib just as much as core. I don’t see that happening with the structure tool – by design it’s a highly specialized, self-contained interface which users are supposed to ignore for more advanced use cases.

    Creating a layer over core Drupal concepts (as opposed to, for example, trying to glue them together better) means several things

    1. There’s very little incentive to fix ‘hard’ interfaces like content types / taxonomy because now ‘only developers use those’. I think there’s plenty of room for improvement for those to make them considerably less intimidating – and would rather see sweeping changes there.

    2. Having to step completely outside the ‘easy’ interface to do something advanced means – a. nasty surprises when you see the ‘real’ interface b. users may not even be aware that the advanced options exist.

    3. If developers aren’t supposed to use the new interface, who maintains and improves it over time? Things in Drupal only get maintained if someone with the ability to fix them is annoyed enough to fix the bug – hence many optional features in core which were designed to make things accessible to non-developers (the teaser splitter, trigger module) being both unusable and very, very broken. I’m confident that the community can maintain a design framework, interface patterns, things like that, but not a single highly complex (under the hood) tool which they aren’t supposed to use.

    1. thanks for your feedback Catch – really appreciate it.

      a couple of thoughts in response:

      1. actually, there’s a lot of incentive to fix ‘hard’ interfaces like content types and taxonomy – I dropped the existing interfaces (well, the views one) into the prototype and made a particular note that ‘interface needs love’ – if we do continue down this path I see that the next big step is to take each one of those existing interfaces that will ‘plug in’ to this tool (content type, blocks, views, for example (ignoring the no-view-in-core for the moment) and fix their interfaces (and, incidentally, I see these as brilliant projects for us to work much more collaboratively with the Usability team and even newbie UX people). These interfaces *must* be fixed in order for Structure to work as they become a part of this system. So, I think that even if developers don’t use this interface they will still benefit from the attention that these interfaces will gain as a by product of inclusion in this tool. Does that make sense?

      2. Again, I would hope this is something we can avoid. See above re: fixing the interfaces, but also a by-product of using this tool should be that you are gradually exposed to and learn how Drupal works and all the little quirks and special names. The advantage of this way is that you learn it by actually applying it in a concrete way, rather than starting with ‘right, you’ve got nodes and they do this, and then blocks do that… sometimes but not always, and there’s no such thing as a page’. We need to be aware that people may want to step beyond the tool and give them a way to do that (that’s not in the design yet but I think it’s a really valid point). We’re not trying to completely hide Drupal from people who use this tool, just help them make more sense of it and learn things as they need to, rather than making them learn everything first and THEN try making something.

      3. I don’t think I said (or at least it’s not my intention to communicate) that developers ‘aren’t supposed to’ use this. I think/hope that they will when it’s appropriate. I’d rather suggest that there are particular types of sites that are best suited to being created using this kind of tool (what we’d be calling the 80% type sites, more than a blog but not something a company with an inhouse development team is likely to create, say?).

      I don’t know who maintains and improves it over time. Perhaps this is a project that should be owned by the Usability team? Would that work? At any rate, I would hope that this would be a tool that the community would be so proud of that pride itself would be an incentive – I still really think this is something that can set Drupal apart from it’s competitors (and that’s feedback that’s come from taking this out and testing it with non-Drupal, ‘Jeremy’ type people).

  10. It’s possible we’re talking at cross-purposes a bit, in which case that’s probably good:

    From the description I read this as a completely separate interface layer to content types, blocks etc. – i.e. you can make a content type using this interface, or using admin/build/types – but they’d be two separate interfaces.

    If instead the tool pulls the actual content types interface into it then that objection isn’t valid – i.e. I can create a content type via the structure tool, or get there directly, but I’m actually using the same interface either way once I’m there.

    This is my main issue with maintenance as well – one content types interface which appears in two contexts (via the admin menu, and via the structure tool) is half as much work to maintain as two interfaces – the old crappy one and ‘magic user interface layer’.

    That still leaves maintaining the structure tool itself – I think we’d need to look at whether it could replace the book (and maybe menu module) interfaces – in which case we lose two large chunks of interface code which have a lot of overlap and potential for confusion in exchange for one.

    1. I really hope (and it is our goal) that we’ll not create new interfaces for blocks/content types etc. specifically for this tool but that the same reworked interface would be accessibly either via the Structure tool or, as you say, you get get there directly. Same interface. The only possible downside to this is that the people who go ‘direct’ may get an interface that is a little more simplistic than they need… but then again, perhaps that’s not a downside at all.

      Replacing Books and Menu sounds good to me 🙂

    1. yes, thanks – we’ve looked at Squarespace – it is quite beautiful, isn’t it! Unfortunately it may be a little beyond our means in the timeframe we have available and given the legacy system we have to work with but it’s definitely something to aspire to 🙂

      1. I’ve actually been known to send certain clients to squarespace and offer to make a quick theme for the tools because it is a tool that they could use. I’ve also seen at least half of those clients turn right around and say they can’t figure it out.

        At some point, we are working with people who will never make a website because they aren’t willing to “break” something.

        Which brings up an interesting idea. If we’re just dreaming still — I’d say the ability to “undo” actions would be a very comfortable way to try something you are not sure what it will do.

        1. good point Josh. I think it’s important to keep in mind that our *primary* (but not sole) audience for this too is Jeremy (ref: who is D7UX for? http://www.d7ux.org/who-is-d7ux-for/), in terms of technical capabilities. I think this also potentially maps to the kind of sites that would be built using this tool – probably something more than a blog (a multi-content type, multi-functional site), but nothing overly large scale and complex – an ecommerce site for a small business, say, but not an online grocery store for a multinational company.

  11. 1. I don’t think we should underestimate the complexity of these other pages (although most suffer from lack of any incremental interface improvements). I like that we need to revamp these in order for structure to work.

    2. Would love to know concrete what learning steps this interface is solving and which steps one has to figure out by being exposed to a more advanced interface.

    3. So the idea behind this, what doesn’t get touched by developers won’t get solved. The installer is the perfect example for this. So instead of saying, we “hope” that developers will also use this – there should be an obvious reason that this is better to use (traditional metrics as it being faster could apply).

    I will try to study this idea more, I am still trying to grasp how all these other elements (content types,menus, views ect) will plug-in.

    1. 1. completely agree. every single touch point with existing Drupal interfaces require lots of attention and improving them is critical to the success of the Structure tool. With out improving the usability of interfaces for block and content type creation, for example, the Structure tool will fall way short of its potential.

      2. the idea is that people are introduced to concepts like nodes, blocks, views etc. through actually choosing the right option to achieve the content outcome they require for their page – that way they start to learn what these things are and a little about what they do, and also some associated functionality like, say taxonomy, again, through trying to ‘make’ something on their website. We need to then make a way for people to be able to say ‘I want to do something other than the options I can see here’ which is where we start to lead them toward a more complete understanding of how you can use these tools. Is that making sense? I’m thinking of Taxonomy, for example, that what it appears to do when you first meet it and what it can be hacked to do are really quite different things… You can get past the obvious uses and even to a kind-of-advanced use in this tool (using views) but there is much more you can use it to do and we will need to point people to *somewhere* that they can learn about this outside of the tool. (which raises a whole other question I’m going to consider out of scope for now!)

      3. Again, I want to suggest that for certain types of sites this will be the fastest and easiest way to build them, and when making those kinds of sites, the efficiencies should make it attractive to developers. Let’s take the ‘us’ and ‘them’ out of it completely and just make it about the scope and complexity of the site you’re building. And yes, the most measurable metric would be speed.

      Bojhan, once we’ve got some kind of agreement that this approach is broadly the way forward I really look forward to working with you and the rest of the Usability Team (and also lots of Drupal developers!) to help work out the minutia – we’re definitely going to need your time and expertise to get it working beautifully and to achieve the efficiencies discussed above with Catch.

  12. I’m ignoring comments. tl;dr. sorry.

    It seems like this conflates a lot of the existing concepts in Drupal. Maybe that’s good.

    That said, I think that will either make it hard for new users to eventually learn the real underlying concepts or…we’ll just have to rewrite Drupal between now and September in order to achieve this. Seems hard (both in terms of code and politics).

    I like this as a menu editor/content builder. I think that some of the automatic changes it seems to make in other things (block/panels, content type) are a bit too “automatic.”

    I like the UX warning, but I’m concerned that the UX warning should be toggle-able. I’m building a site right now that demands a ridiculously deep menu hierarchy, so if they saw the warning every time they add another 4th/5th/6th…level item it would be frustrating.

  13. (where is the “remember my contact info” feature in WP?)

    Also, I love how the pages don’t get deleted but go into an unpublished state. It’s good both because it’s a _good_ idea AND because we had that and it got ripped out.

  14. So I spend quite some hours to really look at this, while during this I approached a few users of Drupal and a few who only used other CMS’s. These are just my first thoughts on this thing 🙂 So read with caution, hehe.

    *Outline/Structure (Sitemap tool)*

    The general impression I got is that people really liked this idea, that you could just put your content into this visual organizer and start building or changing your structure. Although it is not visually scalable in the sense that it will be hard to grasp with more than say 20 pages. I believe this can partly be solved by either collapsing or zooming.

    Also how this intertwines with menu is a bit unknown for me, but assuming that you find a way to handle subnavigation this could be oke.

    This concept could replace the Books and Menu’s current setup, but I for this to work we really need more thought on how it will work with larger menu hierarchies.

    *Site Building tool*

    This is a big beast! I have been trying to comprehend this and this is only early feedback, but there are a few large concerns but also experience opportunities

    *Assigning content on a page*

    Catch: When you create a menu / outline item, you could basically be taken into the panels-esque interface to decide what goes there.

    1. As I spoke with people they (especially those who didn’t know Panels and Drupal) really liked the idea of being able to determine the content of a page and possibly it’s blocks on a page per page basis. But also able to do set blocks on a higher level, which transcends to the lower pages so that it would be able to handle the current implementation of blocks as well.

    2. To me personally it seems like you are proposing a per-page block system, but I know that raises the question whether we are not recreating Panels in a slightly easier interfacing but lacking some of the hard flexibility that you would want. As Jeff Noyes raised, just introducing up a Panels interface, is a really though issue.

    3. Would you really not want to create content from here? I see it rather silly to create an About page, but having to link that about page to an about page. If these pages become containers and pages, where will users understand the difference?

    *Creating a content type*

    So the workflow right now to me seems, you create a upper thing (page?), which forms the content type that can be used for the pages below. This is a bit more visually locked-in then it is now, but I see it could be free-form just as well.

    4. The workflow going from views to content type, is rather misleading and I have this feeling that’s not how you meant it. Rather that it is accessible from multiple points.

    Scenario “You set out to create a team listing page, to list node content as name and job-title. When you want to assign job-title, the concept of content types gets introduced”.

    5. To me it seems people and Drupal think the other way around, from a let me build the node content (so the content type first) and then build a listing to list all this content. Also as Views without any content is a hard concept to grasp, since your preview won’t see anything.

    The place where it should be introduced however is on page level, so as on your initial create a page wireframe you set out to create a page and you are faced with the option to change the form you are working on. I think going anywhere else then this level will only set people off, content types is not the hardest concept to grasp.

    *Assigning views on a page*

    6. Creating a view in a page, this sounds good. (Ignores how blocks will play in this game). In order to explain views you need sensible defaults that explain the concept, such as a example product listing.

    I totally agree that Views needs some love but if you intend to, spend some real time with intermediate users.

    *Taxonomy, Contexts, Finding stuff + all the other things*

    7. To me it’s a bit unclear how this idea will compose all of the tricky use cases that are around Bocks, Views and Content types. As you go out and create so many things at once, how do you expect a user to still comprehend what he is doing?

    8. As talking to users, they seemed to strand on the idea of actually building stuff beyond a really small site (they might have been too ambitious). Also I was trying to understand how when you create all this there is a certain “flow” but I could not answer any questions relating to going back and editing, without getting lost in the mass of interconnectiveness of all functionality that plugs into this idea.

    *Fixing the stuff below*

    Let me try to sum up the amount of interfaces below that will require fixing or complete new ones:

    1. Panels interface
    2. Views interface
    3. Content type interface
    4. Blocks interface (for the absolute blocks)
    5. Taxonomy interface (or at least flow)
    6. Menus interface

    The only interface we have a solid solution for now is Content types, which still lacks over 90% of the interactions that one could have with the new field possibilities. This list scares me a bit, knowing that it took quite some time to rework the current Views interface and making a query builder easier, is not by any chance an easy task. I didn’t even mention the complications of any of this having to be in core.

    As Jeff Noyes said, don’t overlook the complexity of what you are proposing – while it can fail on only one of these interfaces not meeting a certain usability standard.

    9. @ Leisa I hope we don’t have to provide any buy-in but rather testing this with intermediate and beginning users on a low-fidelity (please share) on how they perceive to use this can take some of our worries away. You’re working on a user tool that connects everything together so the most impacting changes are the ones conceptually. If you can explain how this tool intends to solve those or create those, I think we could better grasp what else has to be thought about.

    I like that this is a crazy idea, but I am also aware as Jeff Noyes explained it might be too crazy.

  15. ############################################

    But generally, if you’re adding a path, there’s some route to creating the thing that goes there from within the interface.

    So your workflow becomes:

    1. The idea of a “visual sitemap” is +++
    2. Download CCK and Views
    3. Go to this fancy page
    4. What made my head explode was that later part where the navigation stuff was introduced, and you could click something to move it out of the hierarhcy, etc.

    I should probably try Panels 3.

    …mops brains off floor


    we also need the ‘add arbitrary stuff to a layout’
    ‘give me a something’
    for moments where I’ll building pages which consist of a bunch of other content…

    Core is going to need to store block instances for this to work.
    …it is somewhat near exploding at the moment yeah….

    So your workflow becomes:
    1. Enable a module
    2. Track down its settings
    3. Configure them
    4. Go to this fancy page
    5. Create a page

    But generally, if you’re adding a path, there’s some route to creating the thing that goes there from within the interface.

    I don’t think it’s to hide the concepts entirely
    It’s more that you reach the concept through the process of building the site.

    it would let you just put a place holder if you’re not sure what the page will consist of yet, because you’re only thinking on the sitemap level

    on pages which are in the outline already, recreate the book feature of ‘add a child page’. you build your site from the outliner rather than the admin menu.

    I appreciate how it tries to pull things together but I’m not sure it should try to do it to the level of granularity it proposes to do now

    Is it worth starting a discussion about an ‘outline’ module in core now?
    there is a large window for improvement but we have to avoid killing its simplicity.

    …anyway, back to the movie


    1. +1 to yoroy’s thoughts on creating outline vs. creating content + outline in one.

      MOST less experienced web builders have trouble enough with information architecture.

      If you can easily create a structure, a framework, a set of nav outlines, and then “hang” different kinds of contents off it — that is good.

      The create a placeholder for “about” which then flows smoothly to add a page to represent content for “about” is simple.

      Or add a placeholder for news. Do you want to add a page of content, or a listing of many pieces of content? Click page to choose from a content type, or click listing to go to a “views wizard”.

      I would also feel more comfortable if you could quickly “mock up” an entire site in outliner mode, and then go in and flesh out content in various spots. You might even go from making a listing to creating/customizing the list entry page (aka node/add for such a list entry).

      The Google Sites model might be interesting. You either add a page, or a type of container that holds listings, panels, etc. That is the closest I have seen to this.

  16. ok. it is so great to have you all getting into this and giving your feedback… my general (perhaps optimistic) feeling is that there is a general agreement that there is a need for this tool but that we need to do some work to find the best way to meet the needs of our ‘Jeremys’ without locking them into a halfway house where they can’t properly learn Drupal, or having to completely re-write the way that Drupal works in order to fit this tool.

    it is my sincere hope that through the design and development of this tool we can both make an interface that makes building a reasonably complex site using Drupal fast and easy-ish for less-technical people whilst also tackling some of the more challenging interfaces that everyone has to use no matter how they build their sites.

    now, the thing that worries me is that if we continue this back and forth, we’ll never end up with time to build what we decide we want to build so…. I have a proposal.

    Structure Summit Sunday!

    I propose that on Sunday 7 June we block out some hours (TBC) and get together in #drupal-usability on IRC and sort this out. I’ll find a good collaborative design tool so that we can make stuff and share it and talk it all through until we (hopefully) land on a solution that we’re all happy with (or as happy as we can be!)

    I’ve never done this before so have no idea how well it will work but I think we have to give it a try if we want to get this off the ground, and I really do…

    Designers, developers, insiders, outsiders, Mark & I will both be there…. what do you say? Sound like an interesting idea?

  17. It looks very complex to me.

    I rather would like to see something like a sitebuilder page, where the list view is displayed as a block in a sidebar (see page list in typo3) and in the main content area you have something similar to the actual blocks page, with the ability to drag and drop the different content objects (blocks, nodes, etc.) into the respective regions (similar to the widgets in wordpress). When you select a page in the list view, the content area displays the selected page for editing.

  18. Don’t think I will be able to attend so here is my 2 cents:

    Overall would be a great tool to have. When I approached Drupal the first time – making hierarchical content was very confusing. This would help. FYI a simple hierarchy tool exists in the node hierarchy module- which is a good Drupal citizen but less ambitious than this. Would be good to reference it.

    1. To me the site builder should be a node and views planning/builder tool. I’m not sure that they should include content type creation. Just feels like its trying to do too much. Maybe having some pre-built cck types and accompanying views that could be just optionally turned on (news. blog, event, announcement, others in the 80% rule etc…) and appropriate pointers to create content type would be a better approach.

    2. To the point of requiring contrib modules, what if we could take a similar approach like jQuery UI does – choose what you need and get that in your Drupal download. A kind of install profile on the fly deal – http://jqueryui.com/download. Problem here is – yet another thing to build.

    1. thanks for your feedback Geoff – what you’ve said about more pre-built ‘stuff’ for the 80% rule is spot on, I think, and something that became really clear to me when I took this out to show to some non-Drupallers yesterday. I’m going to do some work on that before Sunday to try to get a clearer idea of how we can make it much more simple and then start to add layers of additional complexity that people can delve into if they want to, but that aren’t required to get a site off the ground initially.

  19. I love this idea. I think a Site Structure like this is the best way for users to quickly understand how to use a CMS. Generally, it helps people to separate ‘Content’ from ‘Structure’ when they’re thinking about managing their websites.

    I always make Site Structure the default e’landing screen’ (the thing you see when you login) when I set up a CMS for someone.

    That said, perhaps we can build on this (http://www.flickr.com/photos/roprice/3593940220/) a little.

    Check out the Site Structure view of a major, proprietary CMS:

    Not the prettiest, admittedly, but effective and usable (if implemented properly).

    Notice the clear distinction between ‘Structure’ and ‘Content’ (and Media, but let’s not get carried away here). This site structure has three pieces:

    1. Navigation Menu(s):
    – equivalent of “Primary Links”, in default Drulal-ese
    – note that there is a hierarchy of pages, although I’m only showing the top-level of ‘Primary Links’. You could expand “Take Action’ to see sub-pages… and move pages around with drag-and-drop

    2. Regions:
    – each region contains one or more blocks
    – in this CMS, as I think it should be in Drupal, regions are set by the theme that controls the front-end website (as opposed to the admin theme)

    3. Archive/Hidden
    -this is for pages and blocks that correspond to content or a tool (ie a form), but which are “unattached” to a region or menu.
    – you might link directly to one of these pages, without wanting it to be part of a navigation structure.
    – this is different than an “unpublished” bucket

    Just wanted to put forth the possibility of incorporating these three pieces into a Drupal “Structure” area…

    As for categories, I do the see logic of putting them under “Structure”, as a secondary screen perhaps — not the default — and with a similar, kind of interface. Makes a little more sense than under “Content”.

  20. first impression of the demo, it reminds me of web publishing tools like frontpage, netobjects fusion, and perhaps dreamweaver.

    the “structure” tool is visual, and appears easy to use. IMO, those are good things for for non-technical and drupal newbies.

    but, who is going to use this tool? seems to me in 2010+ the person this is aimed at will most likely be introduced to drupal via acquia gardens, http://www.buzzr.com, or the like. therefore, I feel it should also be aimed at the set of core modules those types of services will likey use… such as a “core plus” set of modules – even if it is ultimately downloaded by someone and installed in their own environment.

    in any case…

    scope is important. it needs to be very limited in featureset. and that fact needs to be clear – or it may give the impression drupal wont meet the needs of a new user. this tool seems to be a nice edition for a certain type of user. it takes away nothing, but provides a gateway for the drupal newbie. however, like frontpage, netobjects, or dreamweaver, it could hurt new users more than it helps them, if it tries to do too much.

    for example, the publishing tools i mentioned all included some form of “wizard, activex objects, java applets, snippets, etc.” that were either confusing at best or for those technical enough, they were too limited. so if this tool allows you to add widgets or features which require technical know-how to configure and break things if they aren’t configured (properly) are possibly more dangerous – as they will leave a newbie with the impression drupal doesn’t work.

    lastly, (minor) i think it needs a new name – something that more specifically describes what it does.

    * visual site builder
    * visual website configurator

Comments are closed.