Drupal UX IA concerns

Dustin Currie's picture

Hi all.

I'd like to share a concern I have on D7 UX. I loved the usability testing session at DrupalCon (great work guys!), but a big fat red flag popped up when it was mentioned that one member had a problem with the default behavior of orphaned nodes. A tester had a problem with newly created content "not being a part of the site." New content was created, but it wasn't added to a menu, or attached to site architecture in a meaningful way.

I love that a default Drupal install does not impose IA on a developer. If you want a search-driven IA like Wikipedia - you can have it. If you want a faceted tag-driven, IA, you can have it. There is progress being made in the realm of context in Drupal and we'll hopefully get to the point where we can cleverly build context-driven IA. And of course, there is always the option of a menu-driven IA.

Lack of a default IA impedes on usability, but I lean towards thinking it is the responsibility of the site developer or the install profile to establish IA and that this is not an issue to be tackled in Drupal core.




I think that the one of the

dgeilhufe@yahoo.com's picture

I think that the one of the key IA problems in drupal is the lack of discoverability. New users get lost and stop using Drupal. One way to tackle discoverability is intelligent defaults... the problem of orphaned nodes should be solved by an intelligent default that does not prevent folks from using different approaches AND does not impose extra steps on developers that put together a search driven interface.

One approach might be to provide a "system" menu that provides some type of "automatic" navigation structure.

One approach might be just to ship Drupal with a sample data set and move the model for newbies to "modify a model" rather than "start from scratch" All the guys with alternative IAs "start from scratch"

At CivicSpace, we tackled this problem extensively. We settled on intelligent defaults, thats why we invested heavily in the install system and building the capacity for the user to select from many install profiles. There we simply too many different ways people used Drupal.

In fact, there is no reason you couldn't have a page in the installer that allows the user to select a paradigm... menu driven, search, etc, and the default Drupal then conforms to those selections.

That might be an entirely different and potentially better solution than addressing the orphaned node "problem" in core functionality. Just make sure they pick a profile that doesn't orphan their content.

I agree.

Noyz's picture

In this case I think its an artifact of several things, but I totally agree that discoverability is a true problem in Drupal. This can be fixed with install profiles (intelligent defaults by industry and/or usage goals), better menu allocation, and better organization of features - all of which leads to discoverability.

For that specific problem

Boris Mann's picture

I have an idea for that specific problem. A default, out of the box /archive path that shows all nodes on the site that are published. We have the analogous view in /node that is controlled by the promoted flag.

I've filed an issue against core suggesting that this get added to default.profile - see http://drupal.org/node/408858 for the issue and a link back here.

IF we get (more of?) views into D7, we could even go so far as having a view for each content type. eaton's Simple Views trys to do this.

While I'm at it, I should probably go file an issue that /node should be ripped out of wherever it is and potentially be installed as part of default.profile.

My ideas around an Expanded Default Install Profile are here: http://groups.drupal.org/node/19812

KISS it simple :-)

Clarinette's picture

The problem of orphaned nodes is that to create content, you have to go to the "create content" menu, fill in a form, submit it... and watch it disapear to /dev/null... where did my content go? It takes a lot of digging to realise you can find it in administer>content management>content.

Make the content screen the start for all content creation by adding an add button (and maybe a drop down list to select which content you'd ike to add), and when you submit the content creation form, you get back to the content screen where you can see you're newly created content, kindly waiting on the top of the list :-)

Et voilà. No more "where the ... did my content go" frustration.

People can very easily understand that they need to create navigation to link to their content, and they happily do so in both wordpress and joomla without complaing that either is unusable...

User dashboard

Boris Mann's picture

Well, in WordPress, there is no such thing as creating published content that doesn't appear anywhere. And, of course, you only create content on the "admin" side of the website, where you're right on that content management screen.

But that doesn't work for users that don't have admin access in Drupal :P

I imagine Joomla is similar, with its separate admin area.

So ... perhaps a user dashboard is a necessity?

We're working on the add

yoroy's picture

We're working on the add content button on the content list here: http://drupal.org/node/394702

Not enough

Boris Mann's picture

Correct me if I'm wrong, but only admins have access to this content screen?

Maybe not anymore? Admin

Senpai's picture

Maybe not anymore? Admin menu is now split off as it's own thing, so this might actually be a good idea after all.


Joel Farris | my 'certified to rock' score

not yet, but it's pretty

catch's picture

not yet, but it's pretty clear that page has uses for non-admins - we'd just need to make the various things you can see/do on it more granular.