UX Open hours, March 5

Hey, do you have a chatlog available?

CREATE CONTENT PAGE

http://groups.drupal.org/node/214898 => Redesigning the Create Content page => 0 comments, 2 IRC mentions
yes, we finally put out the first part of our work towards an improved content creation screen

Right, so this is really just reasearch and brainstorming - depending on whether we are on track we want to push towards more detailed designs, so we would love feedback!

One thought that immediately crossed my mind: while a two-column content creation form can be great for usability, sometimes you do need the full width for the content fields. Also, let's keep in mind that people may be using smaller screens as well.

If you use field collection for instance, you may want to have a number of fields next to each other
...or if you simply want the width of the body field to match the width of the front-end theme, so the editor can estimate how long his text is going to be

yhea - you should be able to customize it.

two columns is probably a smart default, but not more than that

One of the things I am interested in, is would you use a layout like this for client projects? Does it apply?

Yes, I can see that it would work for the majority of use cases. I have a couple of projects that use Rubik as admin theme, which already places the 'actions' section at the top right, which is nice.

---

MODULES PAGE

So we have been researching the module page for quite some time now, we published http://groups.drupal.org/node/211233 - which has some major conclusions in that the module page is visually overwhelming, which makes it hard to scan and find modules.

With that and a large number of other needs that we identified from these interviews we started sketching:

http://www.slideshare.net/yoroy/modules-pagedesigns

So instead of focusing on everything we can redesign about that page, we focused on the primary part, the individual rows. Again, really interested in what you think about this. It's just a first prototype, but should give a good idea about the direction we are trying to take this.

screenshots: https://skitch.com/yoroy/88mm6/modules-module-page-redesign , https://skitch.com/yoroy/88mce/modules-module-page-redesign

Those are interesting but I don't think they go far enough.

My first impression id that the page is still to long... to me personally, the finding/filtering the list of modules is more important than the row itself.

Yeah. A simple Drupal install already has enough modules to overwhelm you with content. I wouldn't put the description in either.

yeah, we focussed on just the redesign of how a module is represented. Search and filters still a todo

Would love to have a filter on top just like views has when you add a field or filter

I'd really just like to see a module and version and enabled/disabled status.

One of the things that we saw in the interviews, is that descriptions are most often used by more beginners. Who kind of use it to orientate what a module is about.

And I actually personally would eliminate the checkbox and use some other indicator of status. Color and brightness. And on hover, show on/off/uninstall/other information.

Skipping the description is problematic with Fancyname module

Well, one of the things I've been thinking is that we really need to refocus on projects. And less on modules. So the project could have the more visible description.

Nor does removing the desc. win us anything in page height :)

It does, however, improve scannability by reducing the wall of text. Also you could gain page height by going 2 or even 3 column.

ieew

eew

Heh.

Totally breaking scannability :)

Yhea, its a tricky problem, the "wall of text" issue is somewhat mitigated now. That was largely caused by all the dependancy information, and waay to much happening on the screen. The biggest issue, I get from this feedback is that we really still havn't fixed to "filter" or in any way organize this list, to make more sense?

I think we also need to decide if we want to enable/disable modules by checking checkboxes -> save button, or if we want ajax-powered on/off toggles on every row
Well. I know I want ajax powered toggles
I've wanted to be rid of the checkboxes since Drupal 5 but people wouldn't let me.

Right, we have given this a lot of thought. It's a bit tricky, the biggest win of "in-place" on/off toggeling is that you don't lose the context of the thing you are enabling (e.g. you can go straight to its configuration).

Have you considered the design of marketplaces like Firefox or iphone apps? They're basically trying to do the same thing - extend a tools feature set.

I know I've looked at firefox extensions page thinking it's similar. Not a direct inspiration though

The biggst lose, is that we have to design a new "indicator" that shows whether something is enabled or not. It's not really good for scanability, if we just show links.

Toggle button.

Yhea, I have seen a couple of them. Most of them are not really much more usefull than checkboxes though.

I also, and I hope I'm not beating a dead horse, would prefer to shift focus from module to project. For many modules this would make no changes.

But since Drupal core is a project, that right there would make quite a change.

Well, what would it mean visually? With just core? We were breaking heads of what the impact was. Yeah, was especially tough that

Taxonomy doesn't belong in the same box as poll.

Visually, you'd see "Drupal core v 8.0-dev" and then hierarchically beneath it, a list of all modules and their enabled status. The project would have a description but the modules would have their descriptions more hidden away.

I install modules, so think in installing modules, not projects
Core could ship with multipel projects.

But you download projects. Then you install modules.

When the project is named the same as the module, it's good. When it's not, you have CCK. :)

What does that mean though? hierachlly beneath? There is like nesting all over the module page?

So Views, owns "views ui", "views", but also "views bulk operations"?

Stupid question, projects are still something else than packages right?

Tools is a better example.

Packages were supposed to represent Projects but ultimately failed to do that. Packages need to be re-architected.

So one of the benefits is that when downloading a project that contains multiple modules, when I enable the project, I could enable multiple modules at once by enabling that project; it would then enable all of the modules that the project thinks are the 'right modules'.

So what information does this give to user? Frankly from the user research, there was no clear need for more categorisation, or deeper. Just finding the name on the page, mostly.

Also, VBO is its own project, so it wouldn't be part of the 'Views' project.
Right, and that confuses me. Because it is only to benefit, the modules that are "parents" to sort of say.

What is the added benefit, beyond enabling? Hierachy?

The only reason I can think of that user research might have indicated that all you need is to find modules by name is that your users have never dealt with the various cases where they do not know the name of the module they need.

Hierarchy, reduction of information, ability to have the modules page more closely match the update status page. In fact, the update status page could potentially be removed and have its information communicated on the modules page, which is not possible now. But actually, right now I think it's a big WTF that the modules page and the update status page are so disconnected.

Hmm, it still sounds interesting - I am still conflicted. How its going to make it easier, because visually it will require either nesting or hiding - which might benefit a few modules. But generally make it a more overwhelming experience.

I completely agree, and we do have an issue to move the update status information to the modules page. But we'd need to do the same thing for all the other projects that are not modules.

Which is just themes. Since profiles are now just modules.

So far we've been working with the direction to not work in update status info in this list. Though it is very tempting indeed.

Even if update status information is not worked into the page, having the information match is something users would expect.

So on my systems, the update status page is always an easier page to cope with than the modules page.

That's because it's by project. But you rarely want to turn on or off all modules in a project. But you always want to replace all modules in a project at once.

So clearly we have a lot of work cut out for us, I am not sure if we can do everything that is desired though.

Sometimes you do want to turn off all modules in a project at once.
Off, yes. Rarely on.

And when installing a new project, you probably want a set of those modules turned on, and that set is probably always the same. And the project description file (currently does not exist but I would advocate we create one) could say what those modules are.

Alwyas the same for a single site? or always the same for all sites?
I disagree for the later. I'd leave the former to the config initiative

I also take some inspiration from the RedHat installer. Which basically has a 'project' which is a group of systems. You can do 'all', 'recommended', 'pick', or 'none'.

I think that set of modules is the same for most sites. It's not going to be thes ame for all sites because some sites do not wnat, for example, Views UI.

What about modules that currently are packaged with example modules like CTools? You would not necessarily want to enable those with the package?

That's correct. In my CTools description I would pick the modules I think people most commonly want for the 'recommended' set. And it would not include the examples.

Oh I like that.

I did work on that a bit: https://skitch.com/yoroy/88m2e/modules-page-designs, showing 3/5 enabled, using the description to list modules in the project…

Yes! Then maybe the collapsible container to expand and show the modules within CTools and look at them individually if needed. Simple module wouldn't have that as it has only one module.
Also, just so it's clear, if it's needed I will delve into CMI myself and try to make sure that projects have sufficient packaging information to make whatever is needed for a UI like that work.

I think we should just prototype it, I have a feeling that we need to user test this stuff - it will give us a lot more insight if they understand these concepts.

You know I've already promised developer time on this, right? Once we have some comfort with what we want to do.

That's awesome, so the major challange seems to be to figure out the categorisation?

Probably yes. Eliminate packages as we know them, add a multi-value category field, provide a largish set of categories on drupal.org and pull information from it and decide whether to limit them to just those categories or make it wild west. Multi-value will reduce the pain of horrible miscategorization. And might make wild west acceptable. I don't know. But as long as the primary focus is by project the importance is reduced. They're still valuable. And we should have it