Posted by kika on August 30, 2008 at 6:58am
Here is the visual discussion sketch of possible contents and related problems / dependencies of the first-time user help page. We kind-of nailed the contents of the help but it's interaction model, placement and relation with admin, post-install flow etc is still under heavy discussion.
Content
Problems with existing content
- Confusing task structure and order. Should it be ordered or unordered?
- No intelligence
- No internal / external links separation
- No sorting by importance
- Is the amount of content optimal?
Proposed content structure
- Primary: Create content
- Secondary, internal: /modules, /themes, (site config, add accounts...)
- Secondary, external: D.O. links, "embassy of D.O in you site"
Dependencies
- Create content page
- Advanced help in core
- Installation profiles
- Prefilled content
- /admin
| Attachment | Size |
|---|---|
| uxsprint_disappearhelp_sketch_1.jpg | 205.63 KB |
Comments
Related issues
http://drupal.org/node/240721
http://drupal.org/node/233060
http://drupal.org/node/126221
http://drupal.org/node/18340
and
http://groups.drupal.org/node/2828
Some more background
Here is some more background on the discussion we had during Drupalcon on the welcome/getting started page and the help system.
First, let's show you what's wrong with the welcome page:
There is a lot of overlap between the welcome page and the help system. Gurpartap Singh created a new help system for D7, based on the advanced_help module by merlin. This help system needs its own "home page" (the page living at www.example.com/help or whatever the path will be). yoroy made a mockup to aid in that discussion. Here is the mockup, with my own notes attached:
(Unrelated note: the live preview on g.d.o does not show images, and there's no preview button. Sucks.)
Separate welcome and help
Okay, some more notes.
In the discussion we concluded that help should be easily available from every page, perhaps in the upper right corner (like admin_menu does). Help could fold down over the page, pop-up, or be placed in the right sidebar (as a block, iframe, or javascript div update).
elv noted that help in a block has a disadvantage for IE users: if you enter text in a form, click a link in the help block, and then hit the back button, the entered form text will have disappeared.
D7 will have two install profiles in core: one for beginners, one for advanced users. The one for beginners may have prefilled (dummy) content, just like Wordpress has. Should this be default?
We had a beginner in our discussion group, Nestor, who acted as our test user. He said: after installing Drupal the first thing I want to do is create a page. It has to be easy, so I will feel comfortable. Having created a page will make me feel rewarded.
(BTW please note the word "feel". And think about what Leisa Reichelt said during the Drupalcon d.o redesign keynote: "It's all about perception.")
Back to the help page. The help system "home page" should be universally accessible. So it should not contain "state". Therefore we need to separate the welcome text/message from what's shown on the help page.
Perhaps the welcome message could be very simple, just an explanation of how to create/edit a page, and a link to help? KISS! Don't overwhelm the beginner.
Lastly, heyrocker made a remark about something that may be both distracting and important to a new user: what to do after the installation of an out-of-date Drupal version? Show a message that a new version is available? Currently this will only be shown on admin pages.
+1 for Dummy Text in a
+1 for Dummy Text in a Beginners Profile.
While setting up a site for a friend today, I ended up showing a video feed on how to create a page and assign it to the primary links. Within the hour, my friend (first time he ever used a CMS) had about 6 new pages created and assigned to the primary links (now its time to explain on how to manage the menus.)
In the dummy page/story/forum posts, text for a step by step process on how to create a new page/article/forum post (and how to add the same to a menu or edit the menu) could be added.
The crappy dummy content is
The crappy dummy content is one of the 'features' Joomla! offers I hear a most Drupallers complaining about. The problem is that it's relatively hard to get rid of.
+1 for an accessible help
+1 for an accessible help section, but not with frames or JavaScript. Frames are just bad practice and JavaScript isn't always available. There already is a Help link in the menu and I think that's sufficient, perhaps it just needs to be relocated to another menu.
The bigger problem is the use of the help section: there hardly is any concrete information available, even in Core. I think we need to rewrite the texts makes note to self to provide more hands-on information, more insctructions on how to set up a module. Perhaps we need to create a small glossary feature in Core with something like a hook_glossary where modules can define their own jargon which will autmatically be displayed in the glossary section of the Help.
Tasks
Okay, what needs to be done for D7?
Anything else?
I'm working on another patch
I'm working on another patch in #244090: Help text registry based on Robert Douglass' idea to use the menu system which is very promising.
Any overlap
with the Dynamic Help proposal http://groups.drupal.org/node/14639 ?
Sure
During our talks at DrupalCon Szeged we discussed these uses for help:
From xano's explanation I understand Dynamic Help currently serves more like a troubleshooting page (like "in case your module doesn't work, these things still need configuring"). Another part of a help system. And perhaps extensible to more uses. Not sure where this fits in, though.
I don't really get the idea
Videocasts section
There is already a videocasts section (http://drupal.org/handbook/customization/videocasts), though most of the videos are not hosted on the Drupal.org server. I would love to get more thorough coverage of Drupal core than just installing and upgrading so that core help can link to videos on various tasks. I plan to make this a push for the Docs team on D7 (along with writing the Getting Started guide for 7 before we release) regardless if it gets into core or not.
Lullabot loves you
Learn Drupal online at Drupalize.me
step-by-step instructions
The welcome page may have an overlap with the help system but for the rest the the help system could be treated separately where possible. However the overlap between the two is interesting. The welcome page serves partly as a step-by-step instruction. This concept overlaps with the step-by-step instruction many modules provide in their installation instructions. If core help can provide in a framework for helppages like these, is may prove useful for the help-me-with-my-first-drupal-steps instructions provided on the welcome page.
Help for whom?
Whom would we be providing help for? Administrators and/or editors ("end users")?
Advanced help / the new help system is only for administrators; see http://drupal.org/node/299050#comment-1013980.
Editors might need help as well, e.g. on the content edit form. This would probably be a subset of the administrator help.
How could this separation be implemented? And where, in which menu, would the help link(s) show up?
What about filter tips?
What about filter tips? They're help too.
I really don't like the way Advanced Help is being developed as a new Core module. There are too many features still missing or that just aren't allowed in by the few people working on the module.
/me needs to finish his help.module rewrite...
mandatory Video
Having used some Techsmith software recently (Camtasia, Jing) and being totally blown away by the Level of UX they provide (very close to foolproof).
One thing in particular struck me: they almost force you to watch an introductory video right after installation. In Camtasia a Dialog box comes up "Watch introductory video". Well, you can cancel (If you are an experienced user) but as a novice you definitely won't. This video is rather short (5min the most) but very helpful, as it explains the basic UI screen and the most important choices (debatable what this might be for Drupal).
Having talked to Addi yesterday about her plan to have videos for different sections (CCK, Taxonomy, Menu Creation) ready and linked in the help - how about having a small screenshot with a "Play" button - like the typical youtube video - as a link.
What would be important about these videos: the would have to be high quality, very well explained and very short. A great advantage is that the Doc team sees this within their scope of tasks, so quite some synergies could be used without having to do this ourselves completely.
Life is a process
Life is a journey, not a destination
yep
I'd love to see us including references to screencasts in the core install - this will require a lot of co-ordination though - we'll need the videos to be done as late as possible so they're up to date, but a decision on including them quite early.
The intro vids would need to be stored independantly
I love this idea, but should we think up a way to store and reference the tutorial vids without actually including them in the download? First, it'd save on bandwitch. Secondly, it'll make things far easier to update when whenever we need to change the intro or modify a five-second training video without re-publishing a new version of Drupal itself.
______________________________
Senpai ~ Want a better WorkHabit? ~
Joel Farris | my 'certified to rock' score
Transparatech
http://transparatech.com
619.717.2805
+1
I agree as well. I would suggest moving this topic to a new issue though.. I'm sure people will have plenty to say about this.
--
-- matt tucker
pingVision
--
-- matt tucker
Focus on IA
My thinking is that upon completion of the installation, users should be taken straight to the admin page. The admin page should have a very clear link to the new help system which will instructions for getting started. This then establishes /admin as the hub for all their admin and site building duties, giving them a point of orientation. (Note that they will probably still be confused by the admin vs actual site issue, but perhaps slightly less so.)
Obviously we need something to appear on the now blank home page. I agree that this should simply be instructions for putting content onto that page.
This is what I propose for going forward (based a lot on what Gaele says above):
-
www.alanpritt.com
hmm
I like this - definitely for replacing the default node message with 'how to add content here' - we should do that on more 'empty' pages.
So you think at the top of /admin - have a big 'HERE'S WHERE TO GET HELP' message? If we could add a persistent option to drupal_set_message() (or some other way of showing stuff temporarily, with maybe a little 'hide' button on it) - then we could still have a very short welcome message there without cluttering the page.
Encouraging people to use the actual menu system for navigation rather than the welcome message is probably a good thing.
This then establishes /admin
I like this idea. A lot. It touches on the essence of the problem, which is the answer to the question "Now what?" (or "Where am I and what am I going to do?")
However (remark #2 in my first comment was meant ironically), currently /admin is like hell for new users. In combination with your proposal we need to restructure and improve that page.
Admin, Help and Welcome-All In One Page
Mock Up of all in one admin, help and welcome page:
/admin can be the landing page for site installation and the default landing page for User 0 when logged in (currently user 0 lands on user/0 ) and also it can be set as the landing page for certain user roles.
The upper links on the right can be for on-site help text.
The lower/center links on the right can lead to offsite pages.
How about a Help System built on book pages (being built on book pages, admins can add more help pages for sites with many site maintainers/sub admins who can refer to customized text instead of only default help text) within the site? If that were possible a 'View Help' tab can be added in site administration. As of this post, I haven't tried advanced help and I was thinking of a book module based solution as an alternative.
The 'Welcome To Your New Drupal Site' text area can be dynamic and have its text changed according to if the user has created content or not.
I like it. Some
I like it. Some suggestions:
The upper left box "Welcome to your new Drupal site" could serve as a general system status box. Right after installation it gives you the Welcome text and maybe information if there's a newer version available. Once you've done the initial steps in the Welcome text they can go away and be replaced with information more useful for monitoring a site, i.e. the system health.
The Site Administration section is probably not large enough for all the tab content and placed pretty far down. You could gain more space by moving the links section to a block in the primary or secondary navigation, and only show the block in /admin/*.
If the layout is customizable and the user can choose what is displayed, we'd have a useful dashboard, which would be a better starting point for the admin user than the current admin home page.
Dashboard after content is Published
The upper left box with Welcome could turn into a mini dashboard once nodes are created.
I'd rather keep the links within the content area than in the sidebar to keep the links more visible (a block can be created in the event a super admin wishes to have the links available on more screens/pages.) There's no need for all the community links to be listed out when they can be on linked to on a separate page. I'd rather keep all the help within the site in case the site is being built on a hosting environment without access to the internet.
Drag and drop widgets (site administration, drupal links, mini dashboard could all be drag and drop) could be added in a future release.
I added vertical tabs as a possible solution (tabs can have indicators to alert users to newly added links or options) for making site administration easier to use for new comers. Collapsible fieldsets, carousels could be used too.
I'm not in favor of having a 2 column display the way /admin has now. While 2 columns for text reduces page/screen height and increases scannability for long time Drupal users, it comes at the cost of readability (it seems to be easier to look down a list than zig zag between columns when trying to find a newly added item) to newcomers imho.
New Core Help System
I have created a demo site of the most recent patch for the new help system in core. Note that it is in very rough state at the moment, but it should give you a general feel for how it will work. For details see http://drupal.org/node/299050#comment-1030152
Also read Why advanced help? There's a tiny bit of technical stuff in there, but hopefully you can just read past that if you are a non-techy type of person.
-
www.alanpritt.com
screenshot of the above:
screenshot of the above:
Dashboard
Here's my take on how I'd turn the admin starting point into more of a dashboard. I'm sure there are some contentious points in the details, but as a concept I think it would be a nice improvement. (Full View)
+1
I really like the direction that this is taking. I think that a central place for all of this type of information that lives on /admin would be wonderful. Maybe even the ability to change what blocks appear and where... creating an admin-type dashboard gets my vote.
--
-- matt tucker
pingVision
--
-- matt tucker
I'd like to add that I don't
I'd like to add that I don't think this requires extensive new functionality. These little "portlets" could be configured like regular blocks. Layout wise, it doesn't even have to be as flexible as Panels. A standard, fixed 2x2 layout would be quite reasonable. If Views are installed, the user could even easily add his own portlets. The content is already readily available, even though some may depend on core modules that aren't installed by default (such as the site statistics). The "View" drop-down menu to select a different content is the only thing that really distinguishes these from a regular block.
The "setup wizard" is some other idea I've had, and not required for this concept. I just threw it in, because I'd like to see one eventually. It's basically a multi-step flow that guides you through some forms where you can perform (or skip) typical first configuration tasks, such as naming your site.
Time for step 3 - The Funnel
I think that the status box makes a lot of sense. There is a very real need for persistent messages to be displayed on the admin page. It would mean that something like the status updates would not need to misuse the drupal message system like it currently does, and also provides a place to put some other relevant information for administrators (new comments in moderation queue, for example).
I want to press towards a simpler design, however. There are two reasons for this.
The more we try to do, the more complicated the coding will become and the less likely it will get anywhere. We can and will implement further ideas later, but it needs to be iterative.
We don't want to overwhelm the user. I would like new users to be creating content within 20 seconds of arriving on this admin page. That means we will show them that help exists and then let them skip over it until they need it. The more needless stuff they have to read, the more we will slow them down.
With that in mind, I'm a big fan of putting all ideas out there in the brainstorming phase. There are some ideas above which are promising and should be explored in more detail and refined at a later date. But I'd like to try and hone things down quickly now, since this thread is almost a month old and we need to move beyond brainstorming and start refining our ideas.
Let's move onto step 3.
Below is an attempt to put everything we have some consensus on together, while trying to keep it as simple as possible for this next iteration.
The first page the user sees after the install is finished will be the admin page with a new welcome message and a link to help.
The help link, will take the user to the new help system welcome page. More discussion on the contents of that welcome page are over at http://groups.drupal.org/node/13270
Hopefully, they won't need help yet though and will go and create some content, try a new theme or something else creative.
When they have created something, and return to the admin page they get something familiar but more customised to the the not so new administrator...
We also need to take care of the empty front page, which will no longer have the welcome message on it.
-
www.alanpritt.com
You say you'd like to keep
You say you'd like to keep it simple to not overwhelm the user, but the feedback so far indicates that the two-column admin screen with all the options available at once is overwhelming, yet you leave it right there, on the very first page they get to. A link to start creating content isn't enough, because there's so much more that a user should do to get the site into a reasonable state. Be very careful not to leave one group of users out by focusing strictly on those who want to "create content in 20 seconds". Not everybody wants to create a page right away, and even those who do will want to get to other options eventually. These options don't get any easier just because you already created a page.
The common options should be presented outside the context of all the others, so they're not buried. We should at the very least provide the user with the most common tasks after a fresh installation, and you actually move a step backwards by removing some and leave only "create content". Your study showed that putting "create content" last may not have been the best approach, but that doesn't mean it should be the only option. Why not just put it first?
I don't think a dashboard is overwhelming at all. I have yet to find a single user who scores poorly in either quantitative or qualitative tests, and I have a large amount of data and literature to back that up. Large companies have spent years of research and millions of dollars to come to the conclusion that, in the right context, a) they make users more productive, and b) users love them. Intuitiveness, is a tricky measure, but it's safe to say that these kind of interfaces are so common today that many users have some experience with them.
The power is in the flexibility, and you can leverage that to create a better user experience for first-timers. A flexible approach like that allows you to determine what content should be visible after a first-time install vs. at a later stage for example. A first-time install doesn't need to show site statistics and recent content because there is none. Instead it could show external links for example. Coding-wise it's very simple. If Views2 make it into D7 core it would be a no-brainer, but even without Views it's not hard. Starting simple and iteratively building more functionality is a good approach, but the framework to iterate on should be flexible enough to allow for added complexity once you need it.
Already a believer
You don't have to convince me that a dashboard interface is the right way to go. I went off on one about it 3 months ago. Other's mentioned it before me. More since. Now it has been brought up again. Everyone wants the dashboard.
However, what this would actually be in terms of design and implementation has yet to be discussed. Big picture thinking has to turn into the detailed discussion of what the problems are that we are trying to solve with the dashboard and how it will solve them. And whether it would cause other problems. That's what we are doing here. We need to start somewhere. And we can't start with everything. Conquering the disappearing help is our current mission.
The problem is that as soon as you start investigating one problem, a whole bunch of other problems and solutions come to mind to fix them; and so the scope of the project extends. We are very good at doing this and lots of ideas get generated, but little benefit comes of it because we never quite focus enough to break the solutions down into the issue queue and see them through. It's important to keep things moving or we will be here for years before we finish the design... partly because everyone will lose motivation and partly because there is just so much to think about that it will take a long time. And then we would still need to break it down, because grand ideas don't get coded anywhere near as fast as lots of little ones.
It's good to have the big picture to guide us and help us think about how to build the framework, but the framework will be re-written many times anyway. That's how things get developed in Drupal. For example, we may decide that the best way to do this is somehow using the blocks system. But there is talk of completely re-writing the blocks system. You mentioned Views. Nobody yet knows if that will be in the next release, so we have to assume it won't be. Then we will rewrite around its API once it is. It's the forward steps that count, and we now need to take a few steps towards what could become the design you envision.
So is this the right first step? Well that's what we need to decide.
The problem we are trying to solve here is simply that the welcome page we currently have, disappears as soon as content is promoted to the front page. Moving to the admin page solves that disappearing problem, so the concern becomes whether we lose the benefits of the existing welcome page by the change. That's all we need to solve here. Solve that problem without breaking anything and we have a win.
So let's go through all of what the current Welcome page does to see if we have everything covered. I'm sure to have missed some things, but here are my initial thoughts:
--
Welcome to your new Drupal website!
Please follow these steps to set up and start using your website:
--
* A friendly message to welcome people to the site and an obvious first place to start reading. A similar welcome message is also provided on all the above mock-ups bar one. We've got this bit covered.
--
1. Configure your website
Once logged in, visit the administration section, where you can customize and configure all aspects of your website.
--
* Not logged in? Then it should just tell them to log in. Every other bit of information is irrelevant until they have.
* In the new design they no longer have to be told to visit the administration section because they are already there.
* The link to 'customize and configure' just takes them to a subsection of the admin menu. That's no more helpful than just showing all the options on the main admin page. In fact it is worse, because it makes it seem like there is another page full of links to configure when it is actually just a repeat of what is listed at /admin.
--
2. Enable additional functionality
Next, visit the module list and enable features which suit your specific needs. You can find additional modules in the Drupal modules download section.
--
* Now it becomes a bit more debatable whether we are making things worse or not. What this does is to highlight one area that may be of interest to the user at the expense of other areas of the build process. Is a new module more important than rearranging blocks or creating a new type of content?
* We don't actually get rid of this as an option. Instead it is presented in the same place it will always be found in the future. There is a win there in terms of helping users to orient themselves. The issue is that there is a bunch of other stuff in the admin interface that may make this harder to find the first time. We need to tidy up the admin page in general to make things easier to find, but in the meantime are we actually making anything harder? I would contend that introducing people to the admin interface early on is a much bigger win than any difficulties we present in having to look through more links to get things started. And it gives us a good grounding from which to make further improvements to the admin section.
--
3. Customize your website design
To change the "look and feel" of your website, visit the themes section. You may choose from one of the included themes or download additional themes from the Drupal themes download section.
--
* The same applies here as to the last point. We are again guessing what the user would like to do next and sending them off to random parts of the site and to drupal.org to go download more themes. Why put that link there? A link to the contributed themes is mentioned on that actual themes page, so putting it here too is just confusing. It's another example of the numbered list appearing to be simple but it doesn't actually make any sense that anyone would build a site like that. Just because new user's cling to this list, doesn't make it a good thing.
--
4. Start posting content
Finally, you can create content for your website. This message will disappear once you have promoted a post to the front page.
--
* The disappearing comment is obviously irrelevant
* The other bit I've kept in the welcome message, so that is covered too. But should it be there? Should we instead let the admin interface take over here too, like with the modules and themes section? I kept it there, because I thought it was the most likely thing newcomers would want to do first. To be honest, I'd like to get rid of it and make the 'create content' choice more obvious in the general admin section below. But again, we can't do it all in one iteration.
* I think rearranging the list so that content is at the top is the obvious response to the usability test results and anecdotal comments suggesting users want to create content early. But that would be the wrong response, because building a website is not a linear process like that. Again, perhaps this link should be removed from the design.
--
For more information, please refer to the help section, or the online Drupal handbooks. You may also post at the Drupal forum, or view the wide range of other support options available.
--
* So 4 more options. I tuned this down to 1 help link to make this easier. 'You want help, click the help link' 'Do you want support, or to asks questions in the forums, or to use the local help index or our online handbooks?' These extra options can be addressed once in the help system.
* I don't believe I have that link to help correct, nor the welcome message. It needs work.
The stance I take is that you don't make something simpler by crippling the UI. So instead we should present something that looks a bit harder, but is actually just more honest and we say 'look we have a great help system and lots of advice to get you started. Get stuck in, and if you need some advice just click on a question mark for contextual help'.
Then, yes, they get the old broken admin interface because we haven't had a chance to fix it yet. But they now see it without being distracted by a simplified interface in the form of a list. And they are armed with the full knowledge of where they can go for help and where they will always be able to go for help.
-
www.alanpritt.com
Considering the limited
Considering the limited scope of the project, you are certainly right that this is an improvement in some ways. Is it a step backward in others as I contended earlier? That depends on the level of granularity with which you're looking at the problem. Before I explain my reasons why I'm critical of this re-design, let me just stress that I'm an outsider with absolutely no idea about the resources and constraints of this project. It might be the equivalent of storming into a soup kitchen claiming they really ought to solve world poverty instead. But sometimes it's good to be reminded of the big picture, so for what it's worth, here's my argument:
I think you've narrowed down the scope too much to still be able to adequately address the underlying usability problems related to the Welcome page. The real problems are that the user gets disoriented, and that the instructions given to them to get started don't really help them get started, because they're exposed to too much irrelevant detail. You're solving the disorientation for the most part, but you still don't really help them get started or make it less overwhelming. The effort expended at fixing the issue of disappearing help text could well be meaningless if the other problem is solved.
Solving the disappearing help by itself is as easy as putting that on a different page and start there. You could have stopped there, but because you concluded that the admin page would be a natural starting point, you're faced with the problem of integrating the two. The user studies revealed that the admin screen the way it is now is overwhelming to the new user (and let me add straining for the experienced user as well, but that's another story). So if you're trying to help out the users who are having trouble with the welcome page, you're not really doing them a favor by sending them to the admin page. The argument that we're currently leading them there anyway doesn't hold water.
That's absolutely correct, but the conclusion shouldn't be that we can dispense of the link, but that the link should do something more useful. I have several suggestions on how that can be done and could go on about that in great detail if you wish. I won't at this point because I'm still not clear how much you're willing or able to extend the scope.
The other points are similar in nature. They do require a change of scope to really fix. And that's the level of granularity I was talking about. Looking just at the disappearing help text, you're right that you're at least not worse off than before. In the bigger picture however you are making things worse, because you're taking away a potentially very useful tool, just because it currently doesn't do its job. It's akin to amputating a wounded leg because you don't have the time to fix it. It's a useful comparison, because this can indeed become necessary if there is a hard time limit.
So my suggestion is to consider the scope of this. If you only want to fix the problem of the help text disappearing after the first post, the better approach is to put that on a different, separate page and start there after a new installation, and provide a way back there through navigation. Don't put it on admin, because in order for that page to be useful straight after installation it needs to be fixed first. If somebody else fixes this because it's out of your scope, then every change you make to it will potentially be lost. I believe however, that you can do a lot more than that, with not a lot more things to put into the issue queue.
Keeping the links and making them useful would be modest endeavor. You can achieve a lot just by simply having pages with just parts of the admin interface, presenting the options in a clearer and more helpful way, without the distraction of unrelated options. That's a rather small change. If you want to go a step further, turn some tasks into multi-step flows aka wizards. And so on, the incremental changes you can do to further improve that aren't that complex, but only then can you really stop at any time and still end up with an improved overall.
the issue queue
Just to give some background on why it's necessary to keep this process iterative. Every change to Drupal core happens via patches in the issue queue - and only two people can commit patches to Drupal 7 (Dries and webchick). There are up to 1,000 people who'll contribute patches committed to core in any one release, of those, a group of 50 or so people who are active just about every day writing or reviewing patches. There's many, many hundreds of patches waiting to be reviewed and worked on by this group of people - to get patches in, the smaller they are the better - because then me, or someone else, can look at it for 30 minutes, understand exactly what's going on, and give it the green light. With big patches which touch on many areas, 1. people can't look at them in 30 minutes, so it has to wait until they've got time and interest to sit down for an hour or so 2. every time a small patch gets in, it may break the big patch. 3. every error in the patch means another hour or so of someone's time to review the whole thing again once it's been fixed.
So, the only way to guarantee making changes to core is to break things down into atomic tasks which (ideally) can be coded and committed within a week or so. Otherwise, things can sit around for years - see http://webchick.net/please-stop-eating-baby-kittens for more.
With this particular screen, it seems like we could break it down into two simultaneous patches to start off with:
Patch A:
1. Add a permanent 'mini-status report' at the top of /admin to replace our abuse of drupal_set_message()
2. Add a small hook to allow modules to put status information there. Have update status, node and comment as the initial implementations of that hook. The welcome message could probably be handled by the same hook - maybe put it in system module, and set a variable or something once the page has been viewed, or give the message a time limit or something.
Patch B:
1. Remove the welcome message from node.module
2. Replace this with 'you do not have any content promoted to your front page, post an article or set your front page here." for empty front pages - this will be a lot less ugly for site which don't use /node as well.
3. Send users to /admin instead of /node after install.
Patch B might also help with users not knowing what there website actually is - "Am I in the admin section, or is this my front facing site, where's the preview?" etc. etc. a opposed to the front page of their site looking like an admin.
While there's many things we also need to fix about /admin - we've got hopefully 4-5 months more development time on Drupal 7 - so there's a decent chance of getting many more improvements in after these initial patches have landed. Also, at least a handful of people have a pretty good overview of which patches are slated to go in - so the chances of someone snatching the /admin page from under the usability teams' feet in the next couple of months are pretty slim.
that's even more reason not to merge with /admin
Thanks for the explanation; that sheds a new light on it. Those are very rough constraints to work with from a usability PoV, but even more reason to just replace the current welcome page with one that lives somewhere else, and not merge it into /admin. Go back to your original idea of sending the user to a page in the help system, and add a link in the navigation (like "Get started"). After that, you can keep patching the new welcome page, which will be easier to review because it doesn't affect the /admin page, which you said is a likely target for other patches itself. If at any point in the future /admin itself has been patched to a state that it's useful as a landing page, you can start thinking about using one or the other, or merging them.
If keeping the process iterative is the main goal, then this should allow you more flexibility to do so because you're not messing with, and potentially breaking, a moving target.
So while I originally agreed that /admin as a central hub makes sense, the constraints set here make this a poor choice. The original idea of sending them to a help page (doesn't have to be the help system start page if that's something being worked on separately - it could be a separate page that lives within help) is much more practical imnsho.
...
I believe if you have something in mind you should go ahead and say it. It's good to get ideas out there. But it is also important that it doesn't distract us, so it is possible it should be left relatively unexplored for now, or at least explored in a separate thread. These groups discussions have a tendency to get sidetracked in multiple directions which is generally a bad thing. So, without knowing what you are proposing, I'd say start a new thread about it. And I will read it and think about it, but won't necessarily respond until I have time to consider it in depth.
The reason I argue for that page to be 'amputated' is because I can't see how it will ever do its job. That's why I say it is 'fundamentally' flawed rather than just broken. There is no way we can explain how to build a Drupal site in a single page of text; that's why we have the whole new help system we are building. So my suggestion is that we show them the interface they will be working with (even if it is still broken) but we also give them somewhere to look for help. If they become overwhelmed, then that's because we haven't fixed the huge problem of the admin pages yet. But they now know where they can go for assistance, so they are better off than before.
Should we highlight a few areas to look at in particular? Yes, but in the help system I think. And by correcting the actual admin pages at a later date.
Why does it not hold water? All that we are doing now is making things look simple for a few seconds longer by introducing them to a help page before they start. Moments later they hit /admin and get that overwhelmed feeling. They felt overwhelmed before, and they will still feel overwhelmed. The difference is that we have orientated them, and with the help one click away I can't see that we have caused any harm either.
Let me address why I think making the first page a help page rather than /admin is a bad idea:
The experienced developer has an extra step to take before they can do anything. While this is not a major hurdle it still is a hurdle of sorts and this is an important section of the user base.
My second issue is that I believe it makes it more disorientating if an application starts in the help system. You don't know where you are and so end up reading the entire page in a bid to orient yourself with a foreign environment. We've seen in our tests that users read that page thoroughly and start using it as navigation. I interpret reading thoroughly to be a bad thing. It's not natural to read help text all the way through. The natural thing to do is to read it when they get stuck and abandon it as soon as they think they have gained the knowledge they need. If they are reading the entire page of help and coming back to it, that means something is wrong. I believe it's because they haven't grasped what to do with the information because they haven't yet seen what they are meant to be applying it to.
I'm presuming if we direct users to a help page as the first port-of-call, it won't be in a pop up. If it is, then we'd obviously need to load something else underneath otherwise they'd still be stuck in the installer. One of the key benefits of the new help system is it will be in a completely separate window to the Drupal application. This means they can use it as a reference and navigate through their site at the same time. If it is kept in the same window users will have to leave the help system to go try some of the advice out. By having it in a separate window as reference material, they can learn by doing.
Okay, so perhaps that's no worse than what we have now (those problems already exist) and we gain a little improvement by making sure that help is not lost by redirecting into the help system rather than /node. But it still feels like breaking one thing and replacing it with something else that's broken.
But let's not get stuck on that issue for now, because as far as I can see, the only real difference is where users are directed to after installation, which is a one line patch. Either way, several things should happen:
-
www.alanpritt.com
One more philosophical thing
In my experience, the best way to get projects done is to inspire people. People are more likely to be inspired by greater schemes and visions than quick fixes. I believe that's even more relevant in open-source, where motivation is often the only factor, but I wouldn't know.
agreed
So - to get real, how about putting one of the mockups for the dashboard into a functional state? Should be possible with Views and panels, without much programming.
Discussing a functional prototype will be much more fruitful. What also could be nice would be a card sorting similar to Leisa Reichelts to find out what to put where and how the others see that.
The card sort could be very useful for many purposes anyway,
Here some resources: http://deyalexander.com/resources/uxd/card-sorting.html
Obviously Leisa used Optimal Sort for her sorting, which appears to have a limited free version. Uz Card Sort is an open source version, which does not look as pretty and easy to use, but functional and maybe sufficient.
Life is a process
Life is a journey, not a destination
I got a rudimentary
I got a rudimentary prototype and would be willing to make it functional, but this should be discussed somewhere else then.
Revised All in One Page
A more basic layout can be done similar to this image:
A grid layout by default may not work too well for users with smaller width monitors. /admin can use a grid system in a later release (Re-arrange blocks on the top right can link to a admin block set up wizard.)
It shouldn't be too difficult to add a set of help links (external links to d.o for now) at the bottom of the current /admin screen.
Is faceted search going to be available in a core release? The search block in the mock up assumes that faceted search would be in core in Drupal 7 and it can be used to search out only help book pages under a pre-built help book that only super admins can edit by default. If faceted search and a book based help system is out of the question, the search block can directly search d.o with the results displayed in a modal dialog or separate browser window so that users are aware they are viewing the results from a separate website. The search block and help links on /admin are not meant to replace Advanced help since I assume advanced help is available to non-site administrators while /admin usually isn't.
there's an issue for it now!
http://drupal.org/node/423724 : Help landing page: what should be on it, how would it look. Crosslinked this page there as well, needs serious input because at the moment it's just the existing welcome page being put in another layout.
*bump*
Does anyone have a chance to look at the Help landing page?
There are so many good ideas up here.
http://drupal.org/node/423724#comment-2163432
At minimum, we need to change the headings on this page to correspond with the headings on the admin menu.
However, this throws light on two major concerns: the location of "People" management (permissions, listing users, etc dispersed through the admin area) and "Content" management (adding content, managing content types, and fields, again dispersed throughout various parts of the admin area).
Can anyone have a look at this issue? It's sort of a last-chance effort.