We had lots of good ideas at Drupalcon, and even more good ideas here. Obviously a lot of people see the need of improving Drupals Usability. Als probably always in open Source Development, the problem is to organize and actually use the energy to yield results.
So how about collecting the areas to work on here and actually set up teams to work on it. I'll try to name the ones that were already mentioned and add a few.
- Ordering and presentation of Admin backend in General
- How to position Form Fields - maybe use horizontal ordering as suggested here http://groups.drupal.org/node/5338 http://groups.drupal.org/files/tweak.png
- How to order the administration page in general - maybe introducing tabs
- Iconizing: Maybe introduce catchy Icons for better optical structuring
- Structure by optical weight: At the moment everything has the same size and weight, maybe its better to make some things bigger and some smaller
- Common Guidelines deriving from this for module developers
- Easier to access Help pages
- Should create/edit content pages be in Admin or frontend theme
- Should Blocks page be in admin theme
- Menu administration page is not very usable for bigger menus: impossible to create or move multiple entries and much more
So maybe we can collect here such a lot we don't even need a survey anymore. Please Put in your Ideas in Comments. The goal I have in mind is to clean it up in the end to the major tasks to do and then gor for it. Or if we cannot go for everything, maybe we can produce a nice ordered list to make it easy for other people to join in and tackle something.
Comments
Start
I've been quite busy last week, I hoped people would start debating here but I guess we're paralysed by the amount of stuff implied ;)
Obviously we can't work on every usability issue at once, it's a vast and complex job that can be approach on many levels. So at first we could make baby steps and focus on one or two tasks, probably the ones we think are the most important, and see how others (developers, webmaster...) respond to our propositions.
IMHO the admin pages for menus are in need of some love. The wording in D6 has been a bit improved for primay/secondary settings, each menu has it's own admin page to avoid very long and annoying scrolls, but still I think there's room for improvments. Menus are often the backbone if a Drupal website's hierarchy, and as long as there is nothing closer to a "page tree" in core newcomers will find it difficult to grok Drupal's concepts.
What do you think?
What do you think?
What I think? I want that page tree in core! And some jQuery magic. So I can pick up my page icon with the mouse, move it to the right position in the page tree and drop it. Without using those obnoxious weight drop-down boxes!
Effective usability improvements
Drupal has many contributors but the most common contributions come from following up on issues, next by adding patches. There were almost 9000 unique users providing follow-ups to issues in the last 12 months and almost 2000 unique individuals providing code patches.
1)Research has been done on how usability professionals can best collaborate with developers. Developers prefer visual designs they can implement as the best form of feedback. Radical redesigns of the architecture and total changes of work flow wont' be implemented, so don't bother.
2)The Drupal community works effectively through issue queues, so you are correct to clean up the old issues in the queue and start there. A working issue queue is a pillar for getting things done.
3)Understand Drupal's users. See Webchick's personas: http://groups.drupal.org/node/3761
4)Back-up your recommendations with data. If you propose a change, use data to back it up. Either conduct live tests, or get people from the community to provide feedback on your designs. There have been many user experience surveys with data, and conducting 20 quick usability experiments over the Internet is doable.
5)Usability Drive-by's. Designer are loner cowboys. The profession is young and hasn't institutionalized collaborative best practices like software development has. Developers have best practices for working together. Designers need to establish best practices amongst themselves and best practices for collaborating with open source development models. It is very common for designers to show up, express interest in improving Drupal, make some suggestions, provide some mock-ups, and then be gone and never heard from again. We call that a usability drive-by. Don't do it.
6)Drupal is a social network. With almost unique 9000 contributors in the last 12 months, Drupal core maintainers rely on a trusted network of contributors who they know they can collaborate with. They don't want to be stuck implementing a bad design and finding out that the designer has left the project. If you want to make usability improvements, you'll need to earn trust in that social network. Ask around and you'll quickly find people who have made significant usability improvements to Drupal core. Offer your services to some of those most effective user experience developers and you'll find you quickly become very popular. Your outstanding usability designs will not stand alone, without a trust network to go with those designs.
7) Work on something that is going to get into core. In Barcelona, Dries explained what the "7 Features for a Killer Drupal 7" release are. They are:
-Better media handling (James Walker)
-Custom content types in core (Karen Stevenson and Yched, Jeff Eaton)
-Wyswig editor (Look at Kupu in Plone, and talk to the TinyMCE maintainers)
-Better performance (Gerhard, Chx, Jeremy Andrews, David Strauss, Khalid, Dries)
-Better tools to structure and organize content (Nedjo, others working on taxonomy)
-Basic views like module (Earl Miles)
-Automatic upgrade functionality (Earl Miles)
Others like Dries, and Neil have been working on user experience design issues for years already. They have a long track record of asking for help.
Work on usability improvements that have already been approved for core inclusion, and you'll have an impact on tens of millions of people. That will look very good in your design portfolio.
Cheers,
Kieran
To seek, to strive, to find, and not to yield
New Drupal career! Drupal profile builders.
Try pre-configured and updatable profiles on CivicSpaceOnDemand
Good tips
To expand on a few topics:
4) Conducting a survey is easy, the difficult part is getting answers from the right people. And when we deal with end-user interfaces, the last people we want to interview are people from the community :)
Joke apart, we need to interview our clients. Just a few of them really, as people like the controversial usability guru Jakob Nielsen advise to interview no more than 5 for user testing. After all our clients reported to us their recurring issues and difficulties with Drupal in the first place -and I guess that's why we're here to try to solve them- so they may be glad to see we take care of their problems, and willing to answer a few questions.
6) Yeah, that's why we're making baby steps. We decided to work on just a few topics, on existing features we know well, and will show our work in a way or another to the appropriate people in the network -some of them may already read this group, who knows. Then we'll see if the feedback is positive or not :) If not at least we will hopefully have a better understanding of what we can do and how.
7) The projects on this list are mainly dev stuff. I mean, they deal with usability, but in a different way than what we do in this topic as I think we're mostly designers. They add features to achieve tasks in another, better way. And that's great! Obviously that can be done only by people who know Drupal's inner secrets.
Usability is also sticking with what's already here, but we (and our clients) think is implemented in a non optimal way, and try to improve it. But of course we keep an eye on image handling and other features where a good human interface is crucial.
And may be a bit off-topic but an interesting point, even if not only related to Drupal...
5) This is total nonsense and gratuitous provocation. You can't fool us, just admit it was on purpose :) Design as a profession, in the modern sense of the word, has been there since the beginning of the last century. Design IS a dialogue. I can't speak for others here, but I've been studying and working in product design before I switched to the web world ten years or so ago, and I can tell you if we hadn't collaborated with engineers, marketers and everybody involved in a project, we would have been out of work really quickly. The thing is it has always felt like a quite natural process in product design, everyone's a mandatory piece of the puzzle.
On the other hand the open source world usually collaborates with itself. As the name implies, it revolves around code and sometimes doesn't seem to understand code is just a part of the process and can't work alone. So one could say it needs best practices for collaborating with other models. After all, form follows function, and code follows function too. Or at least it should.
It reminds me of the "Image handling in core, for real this time" session in Barcelona. Some developers started saying "ok so we need to implement a new kind of first class object and an API to...". No, we don't need no bloody API. Morten clearly said it during the session: we need to know what people actually DO or how they NEED to deal with images, then decide what's the best way to implement it. If instead we get yet another image object or API, we still won't know how to insert them into content. Once there is a clear workflow for images, once we have identified the function, then we can code and design.
And don't even get me started on Development Drive-by's and the number of times someone has talked about The Great Module idea everybody's waiting for (image handling anyone?), even created a project page, and we're still waiting for the first line of pre-alpha code. Yeah it's unfair, but you asked for it :)
Just my 2 cent.
needs best practices for collaborating with other models.
"So one could say it needs best practices for collaborating with other models."
Right. Getting paid to be the designer on a team is very different than volunteering to collaborate across the design to code chasm in open source. Many of the models user experience professionals rely on, fixed deliverables, customer sign-offs, audience analysis, user interviews, etc provide a solid structure for design led processes.
In open source development, trust that you'll help maintain the code base first, and working code improvements second, put the traditional motivations of designers a distant third. I not trying to discourage you, just warn you where the dozens of volunteers before you have wandered off.
Sounds like you've got a solid mechanism making improvements. You've got strong leadership support for what you are doing. However, there's still a chasm to cross so don't assume that a better design will get implemented. Small incremental changes, in collaboration with core comitters and regular contributors is the way to go.
I am looking forward to seeing your initial recommendations.
Cheers,
Kieran
To seek, to strive, to find, and not to yield
New Drupal career! Drupal profile builders.
Try pre-configured and updatable profiles on CivicSpaceOnDemand
Tabs in administration page
Good idea. The fine-tune button here could be a tab. All default settings could be (jQuery-)hidden in a tab. Let's make the default workflow as easy as possible.
Weights
I wish weights would be jQueried everywhere ! In book.module, for blocks... I can't stand those -15/+15 dropdowns, and clients hate them :)
However with a drag n'drop widget it's probably a bit more difficult to set several items to share the same weight. We should try to keep this feature.
Edit: the Taxonomy_manager from Google Summer of Code 2007 has a jQuery widget to change terms weights. The UI can be improved but it's a begining.
http://mhutterer.at/?q=admin/content/taxonomy_manager/1
Here we go
@elv
I'm with you. Menu management has been treated like a stepchild. Probably because no one used it and used taxonomy structure instead.
so, one of say three points was menu management. What two other points could be equally annoying and urgent because of being annoying?
@gaele: sounds good and not too hard to do. But maybe the Project group "Menu management" can sort out details. What would be the next point for you?
Maybe we got 5-6 Points in the end and can make a simple poll here on Drupal.org on which to start.
O.K. Gaele - I'm just too slow: Reorganizing Admin pages and module admin pages - I'm totally with you.
Three good points. What more?
Life is a process
Life is a journey, not a destination
Stages
Identify, discuss, propose, implement.
At the moment we are still in stage 1/2 (or at least I am, as you can see above ;-). Are we ready for mock-ups? Who's going to do the mock-ups? Are we ready for code?
Is some coordination needed and do we need to first identify all improvement spots? Or is it okay to just start working on some part of the user-interface?
Perhaps we can just start a thread on every subject (like e.g. the help pages) and see what happens?
Or (generating more ideas here) every week concentrate all together on one page/core module, and have a discussion on how to make improvements.
Identifiying spots of Improvement
At the moment we are still in stage 1 or even 0,5 ;) But that's no shame.
So how about collecting some more points and then sorting out a small portion like elv suggested. Then even we two or three poeple could start out with No.1, discuss a bit and assign a task to everyone. Group pressure to yield results will do the rest ;)
And yes, to me coordination is all we need, the ideas have been mentioned and pointed out. But maybe some people join in.
So, Gaele, how about joining up on #drupal-theming on irc this evenig say 19.00 MEZ, the channel will surely not be full. As I feel it, you're just as eager as I am to finally stop talking and doing something sensible. ;)
As I don't know if you are french or canadian, Philippe (elv), I can't guess the right time zone for you...
Life is a process
Life is a journey, not a destination
IRC
IRC is a good way for sorting things out. However, all my evenings are full this week. Let's do it next week on Monday.
Here are some more minor and not so minor improvements I have collected over the last couple of weeks:
Once a node has been created, there is no visual difference in content types. (Is it a page? A story? A wiki page?) At least the content type should be clear on the edit page. (Make content type a PHPTemplate variable so themes can support it easily?) (update: being worked on)
Click on "create content" in the menu, and you'll see the main area filled with different options (page, story, blog, etc.). The same list of options is repeated in the submenu in the sidebar. I'm not sure yet what to think about this, but it does not feel right. Two places with the same content, that's too much.
A related problem appears when creating your own menus, especially pop-up menus like the ones created with nice_menus. Only leaves should be nodes, branches should not (they should be unclickable). My clients often end up repeating the list of leaves in the branch node. This sucks, both for the editor and the visitor.
Two different permissions are "edit page content" and "edit own page content". The first one should be called "edit all page content", so you know what it means without knowing the latter one. (Issue)
admin/build/modules: after enabling module there should be a message telling what to do next.
Fr
I'm in France, 19.00 is fine for me. If I remember correctly most of the people at the usability meeting in Barcelona were also from Europe so others may join us on the channel.
Prioritize
The stages gaele suggests seem appropriate. Looks like you guys are making good progress.
If I might make a suggestion, I would incorporate "prioritize" as an aspect of your identify/discuss work. Perhaps this can be done as you collect features that seem to need usability improvements.
This just an idea that you can take or leave, but, it might be simple to put these all into a google docs spreadsheet or something. You could categorize using categories that reflect the admin user's perspective. Then create columns to mark each issue in terms of:
a) user need
b) technical feasibility
c) business need (e.g. important for some reasons not necessarily tied to this usability review)
* Enter values from 1-5 on column with 1 = low priority, 5 high priority.
As this will be a group effort, it might make sense to prioritize the list of usability suggestions you make so that the important stuff gets done first, in case you can't make recommendations and mock ups for each issue before whatever time you set for yourself as a deadline.
By the way, how did you arrive at the features that need attention? Is there an inventory of issues that came up most frequently on drupal.org forums, email lists, and project issues, or did someone do a pass over Drupal and collect usability issues based on some usability principles? Is difficult to know across the entire drupal project what the most pressing usability issues are according to admin users and developers.
By the way, how did you
We had a BoF at DrupalCon. And some more discussion afterwards in this group.
But you're right, we could collect more issues (e.g. digest these ones: http://drupal.org/project/issues/user_experience).
Meet you on the channel #drupal-theming at 19.00
so for everybody:
19.00 MEZ on the #drupal-theming. We will surely be able to sort out a lot of things.
@gaele: this List looks very good. Minimize double efforts... ;) Meet you on IRC next week, then.
Life is a process
Life is a journey, not a destination
Excellent. Thanks for
Excellent. Thanks for clarifying and pointing that link out. Trying to catch up here.
It's #drupal-themes got the name wrong
Sorry. I'm in now.
Life is a process
Life is a journey, not a destination
Nice chat!
So we decided to focus on:
- menus admin
- admin for content (nodes)
We had a look at some admin screens from other CMSes (@eigentor: could you put the adresses again here?) and will create mockups to share and discuss our ideas.
Michelle and Merlinofchaos told us Panels2 could enable admin pages to be divided in columns, and much more.
What else? We discussed lots of ideas but I didn't take notes :/
Next IRC meeting on monday, 19:00. Tell us if it fits in you agenda.
Plone
At http://plone.org/about/movies there is interesting stuff. "Editing with Plone" shows a few good ideas:
- settings, image manipulations, and other things in tabs.
- a nice links editor
I really like the tabs, probably better than the "settings in left or right columns" idea. Just a matter of taste at the moment, I have nothing against it from a UI standpoint. I think it's an old idea in Drupal, but right now it's seldom used for content, apart from the usual View and Edit tabs.
You can see one with i18n module (or in D6 beta or dev), when you give a language to a node, then there is a new Translate tab.
I think I've seen other module that add a new tab, but I can't remind right now. Maybe a module that added an "Images" tab, but I'm not sure.
Tabs could be jQueryed fieldsets, so we could switch to another tab instantly and it would avoid multiform problems. Plus it would degrade gracefully without javascript as normal fieldsets.
I guess these tabs should be groups of settings or properties, because if any module can create it's own tab it will quickly become a mess!
Protocol of last IRC Meeting Monday 19.00 MEZ
May be a bit unsusual, but sure helpful. Here my personal sum-up of the session:
Next meeting: Monday, 22nd October, 19.00 on irc #drupal-themes
The talk was mainly about how to restructure content editing/creating forms.
We met up with elv, michelle, atritt?(name wrong) and eigentor, later merlinofchaos joined us for a short time, another
user (forgot name completely) joined for a while
We agreed about the following
Michelle showed an example of en editing form. She themed it, but still it was very long. Thoughts were
raised if putting fields into columns or what to do.
Some other examples were shown: the mockup by stdbrouw http://groups.drupal.org/node/5338
http://groups.drupal.org/files/tweak.png (There is also a commented version: http://groups.drupal.org/files/tweak-commented.png )
The admin interfaces / editing forms of
wordpress (click to enlarge)
joomla (click to enlarge)
contentserv (click to enlarge)
Personal comment - especially the contentserv example is surely disputable. They put so much into one place, you lose track again a bit. But
one has to look at the real site with a site less coloured than the yellow one, which is shown as a preview in the middle. It normally looks much cleaner.
And it is incredible how much they fit in the window - almost without scolling. Mostly done with collapsible fieldsets on the left and right side, the big
bars are all collapsibe.
What all of those do, is leave body text editing fields (called "main area"
further down) in the center.
The rest varies. But most systems put part of the options in side columns.
There is still enough room for the main area. Scrolling is reduced.
Font sizes for admin items are often very small, yet readable.
Both wordpress and Joomla put the save/abort Buttons in the top or at least always
within the visible part of the window. In Wordpress there is a very nice "save and edit" button we know
from views and miss elsewhere. All these examples are just for inspiration what could be done,
or how other CMSes do the job - end personal comment
How to restructure the fields technically?
Merlinofchaos showed up and said, much could be done with panels 2. This will not impair performance.
But also Panels 2 has got its limits in restructuring editing forms.
We still have not completely tried out what can be done on the theming layer. But we will find out.
As Neill Drumm already pointed out in the bof: at some point you gotta touch forms.api and implement
things in core.
So we will have to talk to developers when we reach the limit.
We don't intent to hardcode an admin theme. The plan is rather to do one and to provide changes
to the rendering of the forms so theming can be done more easily. Hopefully people will use it
and things can be improved generally.
The other thing that will will embark on soon is the menu editing page(s). This and the admin/content editing
forms are seen to be a big enough issue to keep us busy.
Elv and Eigentor will provide some mockups till next monday to clarify our ideas.
I beg your pardon if I bias things - hopefully not too badly.
Just post corrections. ;)
Life is a process
Life is a journey, not a destination
What time?
When exactly is the next IRC-meeting? Here it says 19:00 MEZ which is German for 19:00 CET which (Daylight Savings Time ends next Sunday) is 17:00 UTC.
At http://groups.drupal.org/node/6671 it says 18:00 UTC.
It is at 18.00 UTC
It is at 20.00 MEZ today. Next week it will be earlier for us Europeans because of the end of Daylight Savings time. Anyway I'll go there at 19.00 and tell everybody to come back one hour later ;)
Atritt and are already instructed. See you there, Gaele!
I find it very confusing that one can post an answer in the middle of a thread - maybe there are pros and cons. ;)
Life is a process
Life is a journey, not a destination
Plone Video
elv, the plone video looks good. Very similar to Drupal, basically with the things that me miss: easy image insertion, a bit more possibilities to rearrange the viewport even for the user. But they also got the save button on the bottom...
The guy is great. Fantastic showcase for wysiwyg editors mostly...
Life is a process
Life is a journey, not a destination
Admin theme
I just wondered, what is your favorite admin theme? Have you ever thought a better admin theme would help? I mean created for the sole purpose of administering the website.
If we can introduce most of the admin changes with a theme, there would probably be a lot more people willing to test and review them.
Aquamarine or glossy blue
Have you tried the above?
They got very small fonts. While one had to make
the main column for glossy blue much larger if
using it for admin purposes (it's a very narrow fixed width
blog theme), but then it's ugly.
And click "hide descriptions" on the main administration
overview page, but you maybe know this.
Yes, I sure intend to create one. It's not possible without doing so.
You show people how nice it can be and everybody goes crazy... ;)
"but nobody go crazy .... for little monkey just like me.
I'm the king of bongo bong." ;)
Life is a process
Life is a journey, not a destination
Themeing to improve usability
I absolutely love the trend in Drupal 6 of theming each module. Many of my usability complaints can be handled now that I am able to manipulate core modules like the forum.
Here are a few things I tend to do in my themes to improve usability
1. reduce menu depth: For common tasks like creating different kinds of nodes, I make sure that a user only has to click once to create what the want to create. This means creating customer menus with menuitems that link to each of the node-type's creation page.
Reduce fonts: The default heading font is HUGE. I only need 10pt and 8pt and quickly go to those sizes. Getting the extra space back from the text make the page look less busy, less cluttered.
Reduce - combine choices: If I want to display recent content, I have only one place where recent content is displayed (forum posts, polls, blog posts, comments). That way users dependably have one place to look at for quick updates. Thank goodness for views.
I'll list more later if I think of them.
Mostly, I think making it easy for drupal administers to manipulate the look and feel of things is a great idea. It would be awesome when we are able to easily manipulate how the admin pages, node creation pages, site summary pages look and feel it will be great.
Software Engineer @ The Nerdery
Organisation
I'm trying to get my head around the current state of usability, what needs to be done, how we are going about it, etc. It's a little overwhelming really!
This thread is a wonderful start, but it is already becoming confusing, difficult to follow, and covers so many topics. I think we need to figure out how we are going to divide this stuff, mock it up, select the most important problems and take them from design to implementation.
Before we prioritise, I think we need to identify all the major issues in one place. The usability issue queue is not exactly ideal for non-software related tasks (e.g. terms such as 'patch' are used frequently), but I think it is the best solution we have. Furthermore, dww is keen to make the project* modules more applicable to non-Drupal and non-software related projects. Eating our own dog food for non-code stuff, may help this effort.
We already have a user experience issue queue (http://drupal.org/project/issues/user_experience), but it is not currently being used properly. Perhaps this is because we don't have a clear idea of how to use it. So let's use it to produce mock ups. Again, the terminology is off, but perhaps 'patch(ready to be committed)' could mean mock-up ready for implementation in this case. So we use this queue to create designs that are thought through enough that coding can start. These plans would then get turned into issues for the Drupal core queue ready for implementation.
-
www.alanpritt.com
Awesome
I just recently found that issue queue too. I've been trying to go through a prune out the bugs and support requests from the ideas and suggestions. Perhaps if we can triage out the bugs to other modules and reduce the issue queue to just the usability suggestions and ideas we can distill the issue queue to a manageable size.
We just need to be consistent in administrating that queue and then it will be useful.
Software Engineer @ The Nerdery
I'm triaging right now
I found some hilariously old issues in the user experience queue. All that I've seen so far have been addressed by some other module or the many releases since their posting. I'm trying to mark as many as fixed and triage them out to other modules as I can.
Update:
1 page down. If you filter on documentation or support requests, you tend to find issues that would be better served it they were triaged. I've handled all the documentation issues but there are about 3 pages of support requests that could be put elsewhere.
I think we should talk to whoever administers the user experience project. Maybe it would be a good idea to change the components and categories to something more relevant to how we intend to use this project?
Update 2:
I just handled all the support requests and triaged a lot of them out. We're down to 6 pages of issues! Going to handle the feature requests now.
Software Engineer @ The Nerdery
Agreed
I'm totally with you. I'm quite new in Drupal and even newer on drupal.org. So just point me to the page you mention. I'm deliberately playing dumb a bit, please don't hit me. Maybe we can use the issue queue for organisation and this place for discussion around it.
Life is a process
Life is a journey, not a destination
...
Yes, I think there are strengths to using this group above the queue for certain activities. The difficulty is working out what. But we can probably do a lot of that by feel. It just takes a little something extra to take the group from enthusiastic discussions towards action.
Actually I think the IRC meeting was an inspired idea to get things moving. So I've given it a bit more attention by giving it its own post in in the group. I've suggested some topics for discussion, but it is a wiki so you can add to it. See http://groups.drupal.org/node/6671
I've edited by comment above to add the link to the issue queue.
-
www.alanpritt.com
More about Input Forms
I found a page that is espacially ridicolous in its waste of space in admin Menu:
The "create content type" page. There is absolutely no need for that form to be that long.
In our recent discussion, we concentrated on content entry forms - which is correct, because
this is the most important - the users see it.
But in "pure" backend forms, discussion might be much easier because there is no main body
text field. It would be easy and make sense to group things horizontally.
When we start out, we also have got to investigate, why and how things are rendered now.
Because there is some logic behind it, that should not be forgotten. Main Objective in my opinion
could be: the forms fields should come out rendered grouped. To me the main body and title field is one group.
The autocollapse options in the bottom of the page are another group, which might make sense to be subdivided (as wordpress does it).
Have a look into the html code (of content entry form, now again) that comes out: the entire
form is inside a div called node-form. Inside that, there are two second-level-divs: "standard" and "admin".
Inside these, every item is single. For theming, it would be enough, if the options that are still inside "standard" get an own div. And what must be not forgotten: depending ond modules installed (e.g. pathauto), more options fields are added. If we design, there must be space left for them.
In e.g. the create/options window for content types, things are worse: there are three sections bluntly called "fieldset". If they would at least come with a class, or an id - here we would go. But I'm sure, if we can make our points and the benefits clear to developers, this can easily (or at least with only reasonable effort) be implemented.
Apart from this, have you read this handbook-page by Angie Byron:
http://drupal.org/node/36602
I think it's very importand for us. I'm gonna translate it to german and publish it
on the german page. I think it can help greatly interact in a productive way with developers.
What do you think?
Life is a process
Life is a journey, not a destination
IRC Meeting on 22nd October
We discussed if to use the issue cue for organizing
We showed some mockups round: eigentors used a second, narrower column for Options
elvs used tabs instead
We discussed if the tabs were confusing, because tabs and body field might disappear when you click on them
We investigated the current use of tabs in drupal, which was found to be often confusing
Gaele showed some nice jquery tabs
We discussed using jquery to get fields right
We
Life is a process
Life is a journey, not a destination
truncated?
Looks like some of your post was eaten. Can you repost or fix it?
Software Engineer @ The Nerdery
IRC Meeting on Mo 22.10.
IRC Meeting on 22nd October
eigentor - Mon, 2007-10-22 21:59
Conclusions:
1.Columns 2.Tabs 3.Javascript (jstools)
Life is a process
Life is a journey, not a destination
My mockups
Editing a node
Listing content types
Creating a content type
They show an attempt at separating the admin pages into logical chunks. The first tab shows the fields you absolutely need to fill. Optional settings are in other tabs.
A standard node Edit page would have 4 tabs:
- View
- Edit, only with the absolute mandatory stuff
- settings, for all the module settings (comments, menu...)
- properties, with node's data (dates, author...). Most of this is auto-filled and probably seldom modified.
Clickable tabs
Ximo set up tabs on a test site
Nice!
Save the node, and then attach the file?
-1 on having to submit the edit form and then attach a file separately. I sort of want it both ways... a collapsed field that is very unobtrusive but gives access to what has been put in "settings" on the edit page, but also separate tabs that list this.
The other possibility is tabs that you can click on all of them, make changes, and then hit submit just once, but...
~ ben melançon
member, Agaric Design Collective
http://AgaricDesign.com - "Open Source Web Development"
benjamin, agaric
Oop-- discussion should continue in the issue queue
http://drupal.org/node/185814
benjamin, agaric
Great
Yeah, thats it.
Meanwhile I also believe tabs are the way to go.
To me it would make sense to move all options that are
not definitely needed directly at the entry form to a settings tab.
The tab system is there anyway for view, edit, translation, revisions, whatever, there can be many.
And maybe in the settings tab it would make sense to use two columns.
So columns come back in ;)
Whis would enable us to reduce the collapsed fieldsets, that impair the
understanding what is found behind them a bit. We could fit a lot of fields
into two columns. What is consuming too much space can be collapsible.
I think I'll mock that up till next week.
So maybe as a proof of concept in the end we have three things:
1 A frontend theme that demonstrates our new tab.
2. A module (maybe panels2) that helps us to pull of the job of implementing it
3. An Admin theme that covers different aspects
If we'll make it into core the first two can disappear again.
Here my original Wordpress-stolen mockups with columns.
Maybe we can make some other use of it:
http://limmertime.de/Dateien/drupal/form-2.jpg
http://limmertime.de/Dateien/drupal/form-3.jpg
Life is a process
Life is a journey, not a destination
I'm impressed
Wow, really good work folks!
I'll think it's the right way yo're going.
I've looked at all mockups and viewed the testsite also and I could spot a little problem (for me only?).
I use the settings very often and it would break my speed down, when I often change the tab. Ok, this would maybe only a problem to me, but what are you thinking?
20/80
Of course your mileage may vary, and I'm pretty sure any solution won't please everybody. I think our aim is to find a solution that suits most of the people. If tabbed admin are made as a setting (activated by default?), you could switch back to a standard long admin page.
Building on last weeks outcome
These ideas take it for agreed that we add an "options" tab to the content/add/edit form and put as many options as possible there. Thus scrolling in the "edit" tab is greatly reduced.
Questions:
(menu has been moved up in D6, input format may be used per field in cck Nodes with multiple body fields)
The "options" tab
Click here: Example of reducing waste of space in menu settings
See you tonight, folks!
Life is a process
Life is a journey, not a destination
help texts
In another thread we discussed this. Two options are
- make "show help texts" a user preference
- add help icons, which would pop-up help texts
The result of both options is that advanced users could leave out the long help texts all together.
Already in admin
In /admin there is a link to show/hide help texts.
It can probably also be used on other pages.
Which settings?
Frank, could you tell us which ones of the settings you use very often?
IRC Meeting on Monday, Oct 29th
We decided to:
Further ideas
Life is a process
Life is a journey, not a destination
One more idea about help texts
Using drupal today and getting angry again (I opened up the input format collapsibe fieldset and realized once more, how annoying it is that the field is so big it forces your browser to scroll down and you lose focus of the body text entry field), I had anonter idea about it.
To bring collapsible fieldsets to en even worse dominance, one could make all the help texts collapsible just as well. I'm thinking of a tiny question mark icon. Maybe this would be very user friendly: if you wanna know more about the particular field you're just about to enter data into, you click the question mark and learn more.
Now a question to all the javascript guys around here: one downside in my imagination would surely be performance ? Many collapsibles sure take long to load? Right at the moment the views admin page is downright ridicolous concernig load time. And I think it is because of all the collapsed field sets.
Another question I discussed with elv last monday is: should there be a checkbox in general admin settings of drupal to show or hide help texts by default? We did not come to an agreement. He said most users will like to have the help texts by default, since most users are not as experienced with drupal as we are. He's probably right there. But if the concept I sketched here is about to make sense, it only works with help texts being able to be switched to hidden with one checkbox. Does not have to be normal install default, for me.
Life is a process
Life is a journey, not a destination
Survey Monkey rules
Just went through the registration Process at https://www.surveymonkey.com/ They definitely rule in terms of usability level. It was again an eye-opener to me at what level user-guidance and sexyness of the UI is at 2007. We should at any rate keep up our endavour - it is just needed to keep the pace!
Life is a process
Life is a journey, not a destination
Help texts
I think it would be best as a checkbox in administration. Not everybody has JavaScript enabled, and it would clutter the viewspace with a lot of tiny questionmarks..
Maybe one could give users three options:
Of ourse, in better wording :)
Shouldn't be too hard to do..? Add the radio buttons to appropriate admin page, add an if.. statement to the section of code that outputs help texts. The third option might be a bit worse. I know I should make a patch for this, will do if I get the time (exams..), but anybody else is welcome to give it a try :)
By the way, shouldn't this be an issue in the Usability issue cue?
Meeting 05.11.
http://kreativmango.no/dev/drupal/node-tabs/
http://docs.google.com/View?docid=dcnngfq5_428c984f7
Gaele is currently working on one
Life is a process
Life is a journey, not a destination
useful screengrabs
Comparing joomla and drupal story creation:
http://www.flickr.com/photos/kentbye/
found it here: http://www.raincitystudios.com/thestandard/a-few-more-badcamp-annotations
Great work
Good comparison.
Hehe, the views admin screen expanded rocks my ass...
- Have you seen John?
- Well, he went to see the end of the views form to press the enter button.
- Oh, so he won't be home before tomorrow. ;)))
Life is a process
Life is a journey, not a destination
Meeting on November 12
We talked about organization of the usability group
Life is a process
Life is a journey, not a destination
Resources for altering the forms
http://drupal.org/node/98253
about theming CCK Input forms.
This could help us, before we dive deep into the api
Life is a process
Life is a journey, not a destination
Split
We should really split this into project pages, with a link in the sticky wiki page. This topic is now buried in the usability group and no longer has any visibility. I suggest those who have a pet project create a page fort it if it doesn't already exist.