If you were at the recent Drupalcon in DC you may have seen Mark Boulton and I at the UX Table plying people with jellybeans and requesting offerings to our Drupal7 UX Suggestion Box. This is just one of the ways that we are hoping to engage the Drupal community in this project and to continue that process, you'll find below the contents of the suggestion box (as of late Friday, unfortunately our desk and all it's contents was trashed on Friday evening (boo!) so it's possible we've missed a few suggestions).
Please take a moment to look through the very roughly (and quite possibly not entirely well) sorted list below - we'd be very interested to receive more suggestions from you or your comments on the suggestions collected thus far.
There are multiple destinations for the suggestions collected - many of these will feed into our thinking for this project, but there are also a few that will probably be added to the issue queue (if they're not there already) and a few to add to a wishlist for releases beyond Drupal7 - don't feel as though you need to censor yourself to only what you think is reasonable to expect for Drupal7 - let us know what you'd like and we'll see what we can do to help make it happen!
Drupalcon DC UX Suggestion box contents:
Information Architecture (Task Based)
▪ Role/Task/Workflow
⁃ Have 'packages' that automatically install common functionality. Talk to Dimitri about install profiles
⁃ CRUD (Create, Read, Update and Delete) admin for specific admin types, terms etc.
⁃ Distinguish between site builders, site managers and site end users
⁃ Better default roles & config
⁃ Workflow improvements to core
▪ 'Feature based' administration/ Add 'features' then configure content types, views, categories etc. for each one. Everything becomes a feature, some that you can't disable eg blog, forum, wiki, required ones for example are 'users'
▪ Bring all options for content types into the same area but also leave the feature config under it's own admin screen (find either way)
▪ I always use Path to define an alias of "login" for (site)/user. Login as the URL makes sense to people and they can remember it
▪ Get rid of Site Building and Site Config. No one really understands the distinction - you just gt used to where to find what you need but contrib modules are randomly placed. Think about tasks instead
Functionality
▪ It'd be nice to be easier to install language pack from core to modules (esp. Thai!)
▪ Node create and edit menu settings. The ability to set the weight of a menu item via the (existing) drag and drop interface but inline with the menu settings and node edit form before saving node
▪ Install modules, themes and updates through the UI
▪ In Drupal7 revisions should be allowed to be published in the future
▪ XML querying gate w module info
▪ Disable menu fieldset on content types that don't need it. Also restrict menu locations
▪ Allow user registration using Open ID
▪ Widgets for user fields
▪ Add data types to CCK fields. This way integers and other data types won't be sirted as strings
▪ Configurable node admin
▪ Smarty type var handling for themes
▪ After running update.php we land on a sreen with links to front or admin - why not just go to Front and probably save a click?
▪ WYSIWYG Theme Builder/Editor
Interface
▪ Fluid project accessible reorder widget instead of arbitrary drag & drop for menus
▪ Content entry screen improvements
▪ Sorting/Filtering
⁃ Improve the admin/content/node page? I often build a view to replace this page. Clients of mine need: Sort by title/type/etc. (by column), Show last updated date (how about a flexible way to choose columns to display) and created date, search/filter by keyword in the title
⁃ Streamline administering roles & permissions (eg. as an option, allow application of permissions on module config pages)
⁃ Allow configuration of all content type settings on single page as well as existing 'per content types' approach. eg comment setting, uploads, etc
⁃ Comment views or CCK for better sorting and control
▪ The date selection shouldn't just be text
▪ Wordpress-like dashboard
▪ Modal dialogs for confirmations
▪ Warn users if they are about to navigate away from an unsaved node or block
▪ Make the UI drag & drop
▪ Increase admin text sizes across the board
▪ Do not get rid of the front end/administration integration
▪ My users want an EDIT button on everything
▪ Smaller /admin page
Search (as in the core search module)
▪ cannot exclude content types - need to, if you have 'database table' types that are just used in views but never directly displaced. [I think there's a contrib module that does this]
▪ need ability to add pages and index them, composite pages like views and panels
Accessibility
▪ Our .gov contracts are v interested in accessibility, particularly in the admin section (since so few CMS platforms have admin accessibility)
▪ Accessibility by default - WCAA 2.0
Additions to Core
▪ Core SSL Support
▪ Bring in token and image API into Core. Should be automatically available not just in separate modules.
▪ Views query builder in core, UI as module (views is a single point of failure, too much risk if there's another views version lag like w/dg)
▪ Image in core content types
▪ Media and WYSIWYG in Core! OMG!
▪ Bring CCK UI into core to bring further consistency
▪ Views in core!
Help
▪ An easy to navigate learning area. Clearly separated sections: learn Drupal, modules / implement learning
▪ Contextual help
▪ Video tutorials in the help area (see Wordpress.tv)
Migration/Back Up/ Export
▪ An export module to make migrating a site to a new server/restored server easier
▪ Build in back up and restore utility for admins
▪ When upgrading an existing site, the site's existing folder and settings should not be over-written
▪ Migration tools that allow easier moves and domain names eg. filesystem path
RDFa
Remove and replace all core themes except Garland
x-posted on disambiguity.com/ux-suggestion-box-drupal7ux
Comments
Good feedback
I'm the one that suggested the reorder widget and apparently it's actually called the Layout Reorderer. It does drag & drop with constraints and is keyboard accessible. Here's a demo (tab to select, ctrl-arrows to move). I meant it as an accessibility improvement but it fits under interface as well.
I also like the suggestion on working over the admin/content/node path. Anyone want to build a voting page for these (or really for core issues) just for fun?
Great Idea
Hello,
This is a great idea and i think Drupal could be a great applications with this feature. I meet lot of customer who want it and i started a prototype. Thanks for the link.
Can we copy the list into a wiki?
You'll keep the UX Suggestion Box alive, and still be able to collect suggestions.
@modulist
@modulist
one word: Breadcrumbs.. they
one word: Breadcrumbs.. they never work as supposed. If I have a structure like this and not using taxonomy
-- Sports
--- Final node about something
The breadcrumb should look like Home -> News -> Sports -> Final node about something
But breadcrumbs only really work when using taxonomy and on admin sections.
Luis
The the way that breadcrumbs
The the way that breadcrumbs work was changed (some would say "broken") as a result of the menu system changes in Drupal 6. Currently, in order to make breadcrumbs work as they did in Drupal 5, you need to install a contrib module such as Menu Breadcrumb, but hopefully this will be rectified in Drupal 7.
Breadcrumbs never really
Breadcrumbs never really fully worked in Drupal 5. I'm aware of those modules, I hope Drupal 7 could fix this problem, in my opinion it's a big usability problem.
Luis
Here's another huge usability problem.
Maybe we can blame Windows/Microsoft for what I'm about to say. From a new user's point of view, it's ridiculous that a new drupal version can't use older modules. I mean, we all understand if the new module can't be used on an old drupal site, but a new drupal site should be able to use older modules. Maybe in a perfect world this could work.
Look what happened to drupal 6.x, it was great, but a lot of guys out there, were creating drupal sites with 5.x when 6.x was ready. I'm not trying to point fingers to the terrific developers of some of the greatest modules like cck or views, but until those modules were ready for 6.x, drupal 6.x was no option for me. So it's not the developers fault, maybe it's the method or maybe.
By the way, I understand this is like it is because of the improvements on every new drupal release, but for a newbie, it's not that simple. At the end I know great things come with patience, Views 2 rocks and Views 2 couldn't be possible without the improvements made to drupal 6.x.
Luis
This is probably not going to change anytime soon
Unlike other systems like WordPress, Drupal makes no commitments to maintaining backward module compatibility with each major release. This is because major releases often make major changes to the system's technical architecture to take advantage of new technologies, or reduce cruft present in earlier releases. There's unquestionably both pros and cons to this approach, but its definitely one of the core principles of the project.
You can read more about the reasons that "the drop is always moving" in this article: http://drupal.org/node/65922
Completely rediculous, but realistic.
If there weren't architecture changes beneath a release, there woundn't be a full number release -- just another 'dot' patch. Its understandable for those who do not code to resent this fact; however look on the plus side... it lets you know which modules are actively maintained! It may be inconvenient to have to make a choice between an upgrade and a module, but look at it from the developers point of view -- would you want to be in the position of not being able to improve Drupal because one or two modules use features that you intend to change :? I think that history has borne out that the collaboration of module developers and Drupal developers has produced the best of both worlds. Anyone who develops and maintains modules understand the virtue of forward development, and plays ball with the latest version. Welcome to open source.
Some thoughts on the content creation cycle
Drupal is a great tool to work with but often a tough sell. Some things that would change that:
Being able to create a child content item directly from a page that is a specific type would be a lot easier than:
1) burrowing through the Admin
2) creating selecting the content type
3) Finding the parent page
I'd like to be able to open a new content input window (popup or Ajax) with the parent page in view.
Front Page Control
The Drupal system manages content wonderfully, but its ability to enable customers to control their own front page is not really stellar "Out of the box". A front page manager would be ideal, with a direct ajax based edit system built in.
The front page of most site is a blizzard of blocks that rarely if ever have traction anywhere else. I would like a specific front page "inner block editor" that allows you to build easy and dynamic lists of content, edit teasers in context, and manage things like whether or not to display comments on the front page, which sets of users see a particular block.
An extra "cherry" would be the ability to simulate a front page view based on a given targets' set of authority group memberships -- or even a specific user.
Home pages are critical to most peoples' business and are taken extremely seriously by most clients -- a tool which demonstrates that Drupal is more front page oriented would make a lot of clients happy.
Excellent correlation on the
Excellent correlation on the front page concept. I'm convinced you were a top notch marketeer in a former life!
EmSpace Lisa
EmSpace Lisa
Contextual Metanodes
Most systems have some sort of (generally thrown together) "Contextual views" wherein a node's title is different based on context. Usual contexts include:
Contextual metadata for nodes (Metanodes?) would give people greater ability to control the views into their content. Having a default teaser view is a good default but more professional users/editors demand a little more granularity in their content management.
Install & Update modules
It would be really cool if you could install/update modules without ever having to FTP or SSH.
Include a module browser in admin, where you can just tick the modules you want to install, and away you go.
Likewise for updates, currently it just notifies you of the update and give you the link. Would be way cooler if you could tick the modules you want to upgrade, and submit, and have Drupal do the legwork.
This would make site maintenance sooooo much easier. Would love to see a single click "Update" option in there too.
eg
Admin clicks "Update":
Now that would be awesome...
I completely agree with this
I completely agree with this comment and would add that this is proving to be a major stumbling block for deployment of community sites with limited technical maintainers. As a group of technical people we tend to overestimate people's ability or willingness to put up with command line or esoteric solutions. The point and click model is effective and efficient for simple tasks, like upgrading a module from one production version to another.
I often hear comments like "It's easy to upgrade modules, you just FTP them up to a site, extract them, run update.php...etc.". These discussions always go the same way with a technical person explaining how a seven, ten, or 15 step process is "simple" and "easy" because they do it all the time and it's all technically trivial work. However, all of the ways I know of to upgrade a module are completely unrealistic for the average site maintainer who is going to struggle with the .gz file extraction before even getting to figuring out that update.php can only be run as User 1.
There are a tremendous number of technical challenges to overcome to make module management better, and it's not going to happen overnight, however, Drupal currently fails to provide a framework for managing modules, and with over 4,000 modules in the wild right now that's a big problem. I'm not sure how many contrib modules the average site has but I'll guess that it's (well) over 20. Given the number and frequency of security and functional patches to modules it's extremely important for the maintenance process to be as easy as possible. This is particularly true for a framework like Drupal, which is used by a large number of small or informal organizations that can't afford to keep maintenance staff or contractors on call.
I see module management as Drupal's next big challenge and it's also one of the few areas that's exclusively a core issue. The Drupal core needs to focus heavily on module management if the community contributions are going to be accessible to the user base, and without those community contributions it's pretty tough to sell Drupal because Core just doesn't have the necessary functionality for most sites. Recognizing the strategic importance of module management is the first step, then we can start figuring out how to better handle modules in the future.
Education is a wonderful thing, provided you always remember that nothing worth knowing can ever be taught. Oscar Wilde
Education is a wonderful thing, provided you always remember that nothing worth knowing can ever be taught. Oscar Wilde
Drupal 7 installation fixes
I've finally gotten a chance to respond to the UX difficulties that Leisa and Mark experienced doing a first-time Drupal installation. There's a lot of really, really simple fixes that can make for a better out-of-the-can experience.
Select an installation profile.
This is begging for an illustration/caricature for each of the two possibilities. I would label them beginner and advanced, as that's a metaphor that you can use later on in the installation and admin process.
Does the advanced/minimal profile take you into a popup with a tree control that lets you choose what you're installing? That's pretty common practice elsewhere
Database configuration
A database icon in the header would be helpful as a wayfinding tool. Each of the form fields should also have a link to a popup or tooltip for help. The advanced options should explain the issues aournd internal and external host names, as they can be showstoppers with some ISPs.
Installing Drupal
The progress bar is a great branding opportunity. Let's make the most of it.
Configure site
The red alert box is a really unfortunate choice for letting users know about settings.php permissions. It implies that something went wrong. A separate "reminder" status is needed.
I'd create a Site Profile entity with the site name and site email address as its properties.
Administrator account
There should be some mention that this is the first user and different from any admin or webmaster roles you may set up later.
I would strongly recommend setting administrator (or the local language equivalent) as the default for the first username and the site's email as the default for the first user's email address.
Drupal installation complete
This should read Your Drupal site is almost ready instead. This should present the user with two choices: start adding content and complete the installation checklist. This is another terrific branding opportunity for Drupal.
Post-installation checklist
This is where a user can finaish their Drupal installation with the following items (and more) in a checklist:
[ ] Clean URLs (these shouldn't be a pre-install "choice")
[ ] secure permissions for settings.php
[ ] set up automatic updates (recommended)
Welcome to your new Drupal web site!
Even if the installer has not added content, this should add a node (node/1 ?) to act as the home page, complete with view/edit tabs. The list of suggestions should appear inside of a message box, separate from the page's content. The message box will have a checkbox that says:
[ ] don't show these instructions again.If you wish to return to them they will be available at sitename/getting-started.
@modulist
@modulist
Clean url part gone
FYI, the clean url check is now gone. It's enabled by default if it can be.
Cheers,
Matt Farina
www.innovatingtomorrow.net
www.geeksandgod.com
www.superaveragepodcast.com
www.mattfarina.com
Re: installation profile
Select an installation profile -- please see expanded default install profile for commentary and suggestions here. Core Drupal 7 currently has "default" (which is what most users will use out of the box) and "expert" (which is for experienced users / developers, and has few features turned on at all).
Many of the other items you mention are config settings controlled by the installation profile.
Thanks for the heads up
The link is quite helpful... but it does point to a different issue: why isn't there one centralized place for people to get design feedback? I understand if it's grown orgnaically, but it doesn't help either designers or developers to hold a dialog at different locations.
Should I post the same suggestions there?
@modulist
@modulist
Fixing the Drupal 7 theming interface
Themes
Screenshots for themes should be twice as large, something like 300 x 200, and in the same column as the name and the description. For more complex themes, there should be a way of viewing multiple screenshots as a slideshow, perhaps as a lightbox popup.
There's a big missed opportunity in not playing up a More themes › link on the page. the current link is pretty bland and buried in instructional text (that folks won't read)
If there's an update to a contrib theme, will this page let you know if you can download an update? If so, perhaps that should be a separate tab, so as not to scare off novice users.
Another missed opportunity is not having a link to the Themer's Handbook or good help content from this page
Theme navigation
This is redundant and confusing as it is. The site navigation should expand to include themes, as in this example:
Admin -> Site building -> Themes -> Stark.
The user should be able to navigate from theme to theme using the site navigation, or a tertiary navigation -- but not through tabs.
Tabs should include constant dialogs that are related to functionality, not themes. For that reason, the tabs should read as follows:
- site logo (now logos and shortcut icons)
- post information
- comments
The default theme should always be shown at top, with other enabled themes below it. The rest should appear alphabetically under an Other Themes header.
Within the themes table, the Configure link should be a button, maybe even a "settings" icon. It certainly doesn't need to have an entire 100-pixel column to itself, though.
Hellish default selections
This is where Drupal costs us person-months in wasted time, particularly on corporate and academic sites:
- please, don't add post data to content types by default!
- please, don't allow users to leave comments to all content types by default!
- mission statements and slogans are generally useless as part of page content. Perhaps making them metadata would work better. If you want content to appear on every page, a block is a far better way of achieving this.
@modulist
@modulist
Why not a Drupal Wizard Wizard?
Hypothetically you could make a drupal "Build wizard" wizard -- allowing administrators to create choice lists and an interface to reflect their needs. If you had an API into an OOP based system configurator, you could create a series of pages in a "Wizard" directory that when in install mode, are stepped through as part of creating a new site.
That being said: there is an understandable reticence to adding features that have a five second half life, over features that have benefits over the entire lifespan of the Drupal project (like fixing the F'n Admin interface.)
Thanks for putting Suggestion
Thanks for putting Suggestion Boxes for everybody. Lots of people will benefit from it. Breadcrumbs never truly completely worked in Drupal 5. I'm conscious of the aforementioned modules. I trust Drupal 7 could settle this issue, in my idea its a huge convenience issue.