Factory Joe's Review

Events happening in the community are now at Drupal community events on www.drupal.org.
You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!
Posted by chx on November 11, 2007 at 7:14am
Last updated by karens on Fri, 2008-01-04 21:59

Copied from http://factoryjoe.pbwiki.com/FeedbackForDrupal6 so people can comment and act on it.

Please help turn the @TODOs into into tickets and patches!

Installation

  • It's awesome that Drupal defaults to install.php if you haven't previously setup the site. That's a much better experience than having to know that you have to hit install.php first. Then again, it also means that you could be intercepted; unlikely but still something to consider.
  • The first step of installation is to pick a language. While this of course makes some sense, I think it'd be better to invite folks into the installation process -- "Click here to get started" as a big button... and then below it have a link to "Learn how to install Drupal in another language." While I don't want to come off English-centric, I think it's a fairly safe bet that you can use English as the primary language for an intro graphic/text and then offer other languages down below -- heck even in other languages!
    • Yes. If there is a language pack, we should offer the selection as a first step. If not, we should start with the database page and provide a link about non-English installs there. This is easy. [chx]
    • chx, I don't think this is a good idea, as it would clutter up the interface and would go unnoticed on the DB page. Chris' ideas seem to be better. [goba]
    • I personally am pretty anti- useless screens you have to click through unless there's a significant usability increase. I'm not sure that's the case here. [webchick]
    • I agree with goba & webchick. An alternative is to have the introductory title and/or copy on the language page (1st step). This would make the initial install page 'friendlier' (which I think is Chris's point) without compromising clicks pages or usability. B/ **@DONE: there's already a node covering language selection here. - marco.h/robotangel
  • Configure Site page seemed too tall. There's a lot of help text in there that, at this point, is probably a bit superfluous, especially for creating the admin user. Why is the site email address different than the admin email, for example? Seems like they should really be merged and turned into a "create the first user" step.
    • We already have a JS to help with email addresses. http://groups.drupal.org/user/6860 chx
      • chx, the JS doesn't work well. as soon as you click out of the field, it copies over, and then it doesn't ever copy again [dmitrig01]
      • This is by design, I believe. Otherwise it would be difficult to set different email addresses for site and admin. B/
  • Shouldn't I set the Site Slogan here?
    • But the page is too tall? Yet you want to put more stuff in it? Requires a lot of text to explain where the site slogan appears. [catch]
    • Nope. [chx]
    • The patch for this should change exactly 7 lines. Too big for Drupal 6? If not I'll do it [dmitrig01]
    • I think setting the site slogan makes sense here, but this is subjective. Meh. B/

Post Installation

  • The first thing I saw after I installed was a red, glaring error notice telling me to check the status report.
  • The second problem was the creation of cron scripts.
  • This is an extremely boring account page. Shouldn't there be some more basic details (please use vcard attributes!)
    • This is hardly what Drupal core needs to do. [chx]
    • agreed with chx [dmitrig01]
    • agreed with chx too, no superfluous functionality in core, please! [Liam McDermott]
  • Why can I block my own account?
  • The timezone picker seems unnecessarily verbose and overwhelming. Must it be so busy?
    • #197442 [marco.robotangel]
    • There are lots of timezones on this earth [dmitrig01]
    • Instead of the current hour-minutes-seconds list ("12:12:00 +02:00") there could be simple list with locale names like "Europe/Helsinki", "Asia/Tokyo" etc. The current numeric, offset-calculated time selection index is confusing since the actual timezone name is unknown. This makes it difficult to have local deployment instructions etc., since there is no way to refer to a constant selection. Ideally, there should be only one selection for "Server location" (geographic area), which would offer default values for timezone, date & time formats and maybe UI and content languages. [htalvitie]
    • I like the idea of selecting time zone instead of offset. But my server is located abour 5,000 miles away from me so not sure how that'd work [catch]
    • Has an issue or patch been created for this? B/
    • There have been issues created in every Drupal version since at least 4.7, but we don't have a good source of timezone names or functions to do anything with them until PHP 5.2, so this can't be done in core until Drupal 7. An interim solution is going into the 5.2 version of the Date API which will overload these forms to set timezone names. [KarenS]

Create Content

  • The Create Content page hasn't changed much... I wonder if you couldn't use icons in there to indicate different content types? And aren't Stories just blog posts? Why not use the more common terminology?
    • #197765 [marco.robotangel]
    • because the "blog" content type is reserved by the blog module, which should only be used for multi-user blogs, not simple one-person blog sites. This is indeed confusing, probably solved by removing blog.module from core [catch]
    • This is Drupal, not WP. People define their own content types. Often those people aren't designers, so icons don't work. [dmitrig01]
    • Although there could be a sensible set of default icons, with the ability to upload more as the admin add their own content types (bit of a 'patches welcome request really :) ). Also a more destcriptive name for 'story' could be 'article'. [Liam McDermott]
    • or 'news', as the 'story' contents are promoted to frontpage by default [elv]
    • I agree 'story' is not as good as it could be. I think 'article' is the best suggestion so far. B/ **@DONE: search/create patch/issue
    • What about the ability to add an icon on the "add content" or "edit content type" page. Then the icon could be used through out the site and configurable? Default icons for core content types would go a long way for newbies and wouldn't really get in the way as long as we can turn them off or better yet replace them. [mhofmockel]

Creating a story/page

  • Wow! The Parent Item listing is huge! Sup with that? I haven't created any content and I'm already lost!
    • This is like saying "There are a lot of menu items!" [dmitrig01]
    • Yes but - some solutions would be to use Ajax to only show the top level at first and then second levels, etc. OR we could make including menus in that dropdown optional and default only primary links to show there. [greggles]
    • Menu parent choosers [chx]
    • Do drupal developers & admins still customize or add to the navigation menu? I haven't ever worked on a project where the navigation menu was madeavailable for non-admin users. What if only the primary, secondary and other custom menus are available in the node-edit & node-add forms by default? Additionally menus could be enabled and disabled. (This could be per role and/or per node type.) I think there is a contrib module that does this. @TODO: Find the module and get this module/feature into d7 core? B/
  • I notice the auto-search users on the authoring input, but frankly, if I only have a few authors, I'd rather have a dropdown... would it be possible to do a mixed input where I could type and get autocompletion OR have a dropdown or people selector to pick an author from a list? Sometimes I don't know people's usernames off the top of my head!
    • there's been work elsewhere to make dropdowns/autocomplete dependent on cardinality, user.module maybe? If so should be used here as well for less than 10 users or something[catch]
    • if (db_result(db_query_range('SELECT COUNT(uid) FROM {users}', 0, 11)) > 10) use an autocomplete otherwise use a select box [dmitrig01]
  • Authored On should be a calendar picker.
    • Contrib. [chx]
    • Specifically, JS Calendar in the JS Tools package. B/
    • Better yet, the jQuery calendar picker -- now in the HEAD of Date API to become the 5.2 version of the Date API, and hopefully in core by D7. [KarenS]

  • Under Publishing Options, Sticky at top of lists still sounds confusing. Maybe stays at top of content lists?

    • #197460 [marco.robotangel]
    • Good idea. [chx]
    • hmm sticky is used in a lot of forum software, I think people know what it means, maybe just "sticky" though, cut the rest[catch]
      • I disagree. Not everyone using drupal has used forums extensively enough to understand 'sticky'. The term took me several months of drupal development to understand. B/
    • A good compromise could be: 'Sticky (stays at top of content lists).'
    • @DONE: search/create issue/patch B/

  • I really don't like where Revision Information is located... If you're going to offer that feature, might I suggest you follow Writeboard's lead and move the Revision checkbox and note closer to the document (only show the note section if Revision is checked)?

    • Again, this is Drupal, not basecamp. We are configurable. Writeboards are not [dmitrig01]
    • the Logs field has always been space that hardly anyone uses, hiding it until revision is checked makes sense. Furthermore publishing options isn't the most coherent set, moving revisions out of it (without asking the user to do a form_alter or form theming) is a good idea i think [ben-agaric]
  • Still not crazy about Input Formats. Even if you allow lots of control, I really wish that Drupal just picked one and stuck with it. If someone wants to override it in the admin sections or in their personal settings, that's fine, but doing it on a per-item basis just seems overly complicated.
    • This is Drupal, not WordPress. [chx]
    • why not just "filtered html" configured by default then let the user configure others?[catch]
    • I think Filtered HTML and Full HTML are basic sensible core formats. I believe "Input Format" could be just "Format", "Text Format" or "Body Format". And most important, I think it should be moved before Body as you usually choose this before you write the body. And also minor: The descriptions maybe removed as links to help are enough. It's wasted space after the first time you read them. Ideally, I'd wish for them to be a show-on-hover help. But that maybe not for core. [alienbrain]
    • Issue about terminology [elv]
      • Resolved B/
  • Menu Settings is just odd. Instead of Menu link title, why not link text?
    • There are many links on the site. [chx]
      • How is that an answer? [dmitrig01]
      • I think chx means that 'link' is an ambiguous term in drupal. B/
  • Instead of Parent Item why not Section or Category?
    • look at the taxonomy module comments for why not category, section would be very misleading here[catch]
    • Short answer; Because Drupal is not Joomla!! :) lol B/
    • Real answer; Taxonomy (the discipline and the drupal module/feature) isn't only about sections and categories. However, I agree that for most vocabularies (flat/non-hierarchical) 'Parent item' doesn't make sense. @: search/create issue/patch B/
  • There's no discernible differences between the Story/Page interface. What's the difference again
    • I think we could lose 'page' in D7, they're only there as examples - this is better handled in docs[catch]
    • I think we could lose 'story' [dmitrig01]
    • Having the distinct static page and dynamic story (article, with author information, published to front page, and comments enabled) types by default is a good thing. They're just not labelled very well in my opinion, see my comment above. [Liam McDermott] agreed should be kept [ben-agaric]
    • I don't think anything should change except the text; 'story' -> 'article', and node-type description is also quite long. Can we communicate the same meaning more effectively in less words? B/ **@DONE: search/create issue/patch to communicate the same meaning more effectively in less words
      • #197825 [marco.robotangel]
      • I disagree. In my opinion the description isn't too long. It describes what the type is meant for and gives examples what to create with it. Isn't this userfriendly?
      • #197775 - a small addition to the story/article issue. Should be clear what is meant alone by reading the title then. [marco.robotangel]
  • Under comment settings, the language is confusing. Instead of Disabled, how about Off? For Read only, how about Closed? And for Read/Write, how about Open?
    • I completely disagree with this suggestion. the suggested terminology doesnt describe the functionality at all and in some way is misleading [litwol]
    • I agree with litwol [dmitrig01]
    • I don't think 'off' is an improvement on 'disabled'. However 'Disabled' isn't very clear. I thought of 'No comments' but I don't think it's any better than 'disabled' or 'off'.

Administer

  • Wow, that's a lot of options! Yikes!
    • This is Drupal, not WordPress. [chx]
  • Ah, phew! Great to see the "hide descriptions" link...! Maybe they should be hidden by default and then turned on per section instead of all or nothing?
    • Definately not. How would newbies orientate themselves without that help text? B/
    • would make the page shorter, not a bad idea [catch]
    • I think so too. I wonder where this stuff is set. [dmitrig01]
      Issue and patch here [catch]
    • Administer page huge usability boost: Issue: Direct links to pages that are tabs within the listed pages [ben-agaric]
      • +1 for links to tabs on /admin, either in addition to, or instead of description. B/
      • +1 for admin link saswell - possible make it red to warn users that theyre admin, and can break stuff? Would it be better to make an admin users, then a regular users who can post content, or would this add over-complexity to things? Nickweb

Content Management

Categories

// Forms tidied up, drag and drop is in, renamed back to taxonomy to avoid "Categories" confusion", help text rewritten - I've strikethroughed stuff that's been dealt with more or less. [catch]

  • in the first sentence you mention the taxonomy module. Replace "The taxonomy module allows you to classify content" with "Categories allow you to classify content".
    • covered above B/
  • Ugh, I remember "vocabularies". It's so Semantic Web it hurts.
  • Perhaps you can move the "more help..." link into the main paragraph: "Read more..."
  • Add vocabulary is a really terrible name. Why isn't it just "Add Category"?
    • Maybe because vocabularies are not categories. [chx]
    • I think the terminology "vocabulary" is the confusing part. Categories are the new name for taxonomy, Term is fine, but the vocabulary part is the one that is confusing. Renaming that to "category item" or something else, may help, as long as it is not a "vocabulary". [kbahey]
      * There's a consistency problem. The help text says "The taxonomy module allows you to classify content into categories and subcategories", but the only button is "Add vocabulary". [elv]
    • Taxonomy >< Terms >< Vocabulary. Categories are merely a subset of 'Terms'. 'Categories' is a potential Vocabulary. The word 'Categories' has no place in the taxonomy module. In order to support drupal's killer feature (aka Taxonomy), drupal needs three different terms. The user needs to either know or learn a bit about taxonomy (the discipline) to understand this. @DONE: Can the help text be improved for d6? See below. Alternatively, offer some vocabularies by default to get started. Although thats what install profiles are for. @DONE: Create an issue on this for drupal 7 B/
      • #203051 [marco.robotangel]
        * The hint for "Vocabulary name" isn't very useful. Example: "Topic" doesn't really give me a hint as to what I should type... how about "Greg's Wedding" or "Technology" or "My Summer Vacation"?
    • I agree, but I think the example needs to include both a category/vocabulary name and a couple of terms that would be included. For example, "'Mammals' is a vocabulary whose terms could include 'dog', 'bear', 'mouse'. [Shai]
      • Your example explains what a vocabulary is much more clearly than the current 'The name for this vocabulary. i.e. "Tags".' @DONE: search/create issue/patch for the above help text, and refine it. B/

  • While I kind of understand why I should set Content Types here, I really don't. Why not just make them available to all Content Types?

    • Because that would make the poor, poor node add screen even taller. Also because I might have vocabularies that are just not fit to certain content types. [chx]
    • Does the node type selection need to be required? Isn't it possible to use the taxonomy module for more than categorizing nodes? [dwees]
    • Yes. Taxonomy.module can be used to categorize entities other than nodes. and it's not required here
      * Hierarchy: This is where it gets screwy. I believe we talked about this before too. Why not make all Vocabularies multiple and just leave it at that?

    * Related terms: Why not just enable by default? The Help Text here is also not helpful: "Allows related terms in this vocabulary." Uh, duh?
    * Free tagging... Ok, this seems like a good feature, but is confusing. It sounds to me like this is an interface feature. Why not remove the hierarchy option and ask: "Hierarchical Terms or Tags"?
    * I think one could start with a hierarchy of terms, then turn freetagging on, so both would be used? [elv]

  • Multiple select is the provence of tags, so if you've got tags, you've got multiple select (forcing one tag isn't really folksonomic, now is it?). If you want multi-select in your hierarchy, ask in the hierarchy section.
    * Reckon a lot of this could be made simpler with just an 'advanced options' fieldset [catch]
    * I Agree. @TODO: search/create issue/patch B/
    * Required. Ok this is fine. But you used the word node.
    * Reference to node removed, see http://drupal.org/node/191104. [keith.smith]
    * For weighting, I wonder if you couldn't simply move this aspect out to the main Categories page -- sorting visually, rather than by number, as in Mephisto.
    * Quicksketch is working on table row dragging. [chx]

Adding terms

  • Okay, a term is clearly a category... but this is not clear from the labeling.
  • Why do I need a description for a term? AND for a vocabulary?
    • If Drupal core does not display this anywhere (does it?) then why it holds it? If a contrib module wants to do something with maybe it can provide the table, too? [chx]
    • Always used to in rss feeds, now it does it at the top of taxonomy/term pages - patch went in this week [catch]
  • What are Synonyms used for?
    • See above. Yes, a full blown taxonomy needs these, but a full blown taxonomy does not get you laid or something so we might not want to keep it. [chx]
    • There's a nice issue against D7 for using synonyms to catch free tagging bloopers, would save me several hours per year cleaning out mis-spellings etc., if that can be done simply in contrib then yeah, lose it from core [catch]
      * Again, visual weighting seems preferable here.
      * It would be neat to organize the taxonomy term weights much how the drag and drop blocks and menu system are done. [Rob Loach]
      * Visual weighting would also remove the need for the awkward Parents combo box.
  • Related terms is useless until you've added more than one term. And, shouldn't Drupal calculate related terms? It seems odd to do this manually.
    • It depends how you use related terms... Setting it manually makes sense. [elv]
  • The actions on this page should be "Save term and add more..." and "Save term". Going back to the containing vocabulary is not possible without going to Categories and THEN to the vocabulary... too many clicks!
    • There is a breadcrumb but still this is a valid idea. [chx]
    • I agree - there should be an "add terms" fieldset in the list terms section, with an autocomplete textarea for this and ahah submit so you can immediately drag and drop after adding. [catch]
    • Isn't the breadcrumb enough? There's also the navigation block. Two buttons will generate more mistakes ("ah damn I'm back to the vocabulary") than it will save clicks IMO. [elv]
    • I Agree. This improves navigate-ability. @TODO: search/create issue/patch B/
  • The Delete button for a term should be a text link.
    • Why? [chx]
    • Probably because you're less likely to click it by mistake if it doesn't look like the Submit button. Especially as the buttons are next to each other. It has also been discussed a bit for node edition pages, in the usability group. [elv]
    • There are arguments both ways here. Links next to buttons look funny and inconsistent. But having a button to submit-and-delete a form of data is contradictory. I think 'delete' shouldn't occur in forms. It should be a local task (but not a tab), and a table-action on admin/content/node. B/

Comments

  • Shouldn't Approval Queue be Moderation Queue?
    • I agree. B/ @DONE: search/create issue/patch
    • #201490 [marco.robotangel]
  • It would be nice if, like WordPress, Drupal started off with a default page and a default comment, to show what content in the system looks like.

Content

  • Seems like a regular search box would be useful here in addition to the Filter box.
    • yes it would, there's an issue somewhere. back here later with it hopefully [catch]
      • @DONE: search/create issue/patch
      • #201493 [marco.robotangel]
    • I think the filters could be vastly improved for usability. This is a good use-case for where design patterns would work and be useful; http://groups.drupal.org/node/7294 B/
  • Again, not having any default content is kind of a bummer.
    • one node to hold the default message maybe, but deleting any more than that would be a 'bummer' as well[catch]

Content types

  • Maybe offer a link to show all Content of each Content Type -- i.e. a link to a prefiltered content search?
    • Sounds like a direct link to admin/content/node where "type is xxx". [elv]
  • I will say that this section is fairly simple and straightforward, though I'm not sure it's entirely clear what content types are!
    • @DONE: improve help text in d6. search/create issue/patch B/
    • #201566 [marco.robotangel]

Add content type

  • Some typos: Replace It is recommended that this name begins with a capital letter and consists only of letters, numbers, and spaces. This name must be unique to this content type. with It is recommended that this name begin with a capital letter and consist only of letters, numbers, and spaces. This name must be unique.
  • The machine name should be auto-generated onblur().
    • Could be a good idea, but removes a tiny bit of flexibility. [elv]
      • It would still be editable after onblur() B/
      • #201565 [marco.robotangel]
    • @DONE: search/create issue/patch B/
  • Hyphens should be allowed!
    • Wouldn't it conflict with phptemplate .tpl filenames? [elv]
    • Hyphens have been restricted for very good technical reasons (urls, filenames, database...) B/
  • Under Submission form settings, the minimum number of words should be a text input, not a dropdown. Why would you rename the Title and Body fields? Seems like unnecessary customization.
    • You might want to create a custom content type and rename the fields to make it even MORE obvious for a novice user. For example renaming title to 'Your Name', etc...
    • Renaming the fields is definitely a good thing. The dropdown is ia good hint of what are "a lot" and "a few" for newcomers. [elv]
    • I Agree. B/
  • What's the difference between Description and Submission Guidelines?
    • It's explained on the content type creation page, under the fields! [elv]
    • Obviously Chris had a problem understanding that text. @DONE: search/create issue/patch to improve the help text B/
  • Why not rename Workflow Settings to Default Settings?
    • I don't think this is an improvement. 'Default Workflow Settings' might be. Meh. B/
  • Seems like Create new revision should be renamed to revision control.
    • No. The default behaviour is exactly that, a new revision is created, not just the revision control enabled. [elv]
  • Comment Settings... OMGWTFBBQ?! Again, why so much customization? This is overwhelming! On/Off/Open seems sensible, but all this threading stuff? Moving comment controls around? I dunno, I'll let this one go, but it just seems like too much stuff!
    • This is Drupal, not WordPress. [chx]
    • Agreed with chx, particularly when you consider comments are also forum posts. [Liam McDermott]
    • I'm going to open an issue to remove "most recent first" as an option in D6 - it was used on groups.drupal.org for a while until there was a petition to take it off in irc. Views 2 is likely to allow for stuff like this anyway.[catch]
    • @DONE: search/create issue/patch to move some of the more complex comments settings into 'advanced settings' fieldset B/

Post Settings

  • Number of posts on main page: This is where help text would make more sense beneath the title, rather than beneath the input box. Perhaps this should be a text input, with a maximum specified?
    • Here again a text input is less friendly to newcomers. [elv]
  • Length of trimmed post... How about Length of post preview? And instead of characters, you should use word-count, since that's what you used in Content Types! Consistency!
    • Makes sense to me. Trimming is way to cut posts to approx the same visual length, so characters are appropriate. Minimum post length is more about content, so words are useful because there's a huge difference between the number of characters in an english and a german sentence. [elv]
    • Looking into this I wonder why "Length of trimmed posts" is not just "Length of teasers", and "Unlimited" is not just "Disabled". [gaele]
    • If we use "Length of teasers", then Unlimited could become "Full post" or "Full content". [elv]
    • Also, the trimmed post is not the teaser. Teasers have other fields that don't get trimmed by node_teaser() (which is what this setting applies too).
  • Preview Post... This is where one-line options would really improve Drupal's interface. All you need is the line: "Must users preview posts before submitting? Yes No "
    • Yes/No settings would require us to read the help text to know which one we want to check. Right now we can just read the title of the fieldset and the checkboxes text. [elv]
    • What he means is moving the description to the label. [gaele]
    • @DONE: search/create issue/patch to remove radios, add checkbox 'User must preview posts before submitting' B/
  • Why is there a reset to defaults option here? There are only three options?!
    • Even if there were only one option: the reset is helpful in case you forgot what the default was. [gaele]
    • Other settings pages don't have 'reset'. Reset is useful here because tweaking 'Length of Trimmed posts' is tedious work. B/
    • I think Chris thought 'reset' was the old-school type="reset" button. B/

RSS Publishing

  • You should really offer Atom.
    • It is RFC 4287 now, indeed. [chx]
    • @DONE: search/create issue/patch B/
  • This section should be renamed to _Feed Settings_
    • Perhaps 'RSS Feed settings'? @DONE: search/create issue/patch B/
    • #202020 [marco.robotangel]
  • FeedBurner integration would be a nice plus, but that's a little proprietary.
  • The wording here is a little awkward. Number of items per feed... how many feeds are there? Why not just Default feed items?
    • Default feed items suggests some stock content in rss feeds if no posts in them. How many feeds? No way to count this, I have '00000s on my site [catch]
    • I think it is not obvious from the help text that drupal sites typically have several rss feeds. @DONE: search/create issue/patch to change 'Number of items per feed' to 'Number of items in each feed' and 'The default number of items to include in a feed.' 'The default number of items to include in each feed.' B/
  • Remove XML from Display of XML feed items; instead how about Feed content? Also remove XML from the help text.
    • @DONE: search/create issue/patch to change 'Display of XML feed items' to 'Feed Content' and 'Global setting for the length of XML feed items that are output by default.' to 'Global setting for the default display of content items in each feed.' B/ - See 202026 - [marco.robotangel]

Site building.

  • Wow, spartan.
    • WTF? B/

Blocks

  • A preview of the section of the theme... I like that. What use are these generous preview areas if I can't drag stuff into them?
    • http://drupal.org/node/181066 by quicksketch [chx]
      • Quicksketch (and everyone else IMHO) is missing the point here; A table doesn't make sense for organising blocks. Organising blocks is essentially basic layout design. Users should be able to click and drag example blocks within drupal regions, and from one drupal region to another. @TODO: A table is the wrong design pattern on admin/build/blocks (wireframe!). Drag and drop rows doesn't fix that. B/
  • Ok, it is nice that when I change the dropdown menu, the item moves... but I really should just be able to drag and drop these content chunks up and down to different sections. http://drupal.org/node/181066
  • This needs some work: If you want certain blocks to disable themselves temporarily during high server loads, check the "Throttle" box. You can configure the auto-throttle on the throttle configuration page after having enabled the throttle module. How about You can auto-disable certain blocks during high server load to reduce stress by enabling the "throttle" option. Perhaps Throttle should be enabled by default?
    • IMO default disable is OK. [chx]
    • definitely ok - be default would see content disappearing arbitrarily from people's sites at default traffic levels for throttle.module. Do we need block throttling when they're all cached - in D7 maybe take it out and just throttle modules??[catch]
    • The suggested new wording is an improvement, though. [gaele]
    • @DONE: search/create patch/issue to fix the wording B/
    • patch http://drupal.org/node/199890 [gaele]
  • The introductory text is useful, but it strikes me that the interface for managing blocks is halfway down the page!! Not to mention that, but when I apply my changes, the success notification shows up below the text. Totally not standard. It should be above the text.
    • In general we might want to move menu_get_active_help to the bottom of the page. But then, pressing end won't land you on a submit button... [chx]
    • How often do people read this text? It should be possible to hide this text, just like "hide descriptions". See this discussion: http://groups.drupal.org/node/6297 [gaele]
    • @chx and @gaele. No and no. Quote Chris; 'The introductory text is useful'. The issue is that there is a lock of consistency in location / layout of the error and status messages. I believe this is a theme-layer issue @DONE: search/create issue/patch to fix this in core themes B/
  • The list of themes here is really confusing. I don't get it. This is not where I should be picking my theme.
  • Why isn't the name of the block a link? That's what I should click to configure the block.
    • yeah nice idea if it doesn't affect drag and drop [catch]
      • It doesn't affect the drag and drop. B/
    • @DONE: search/create patch/issue to make the title link-able, remove 'configure' from the operations column. B/
  • Weight seems silly on this section when you're moving blocks around with Javascript anyway. Why not do this visually, as I've suggested for other sections? Again, Mephisto gets this right.

Block configuration

  • Ok, another unnecessarily super tall page.
    • @DONE: search/create issue/patch to collapse 'role' and 'page specific visibility settings' B/
    • #202183 [marco.robotangel]
  • Setting a block title is weird. What's this? Use to display no title, or leave blank to use the default block title. Why can't I just leave it blank for no title? Perhaps this input should be filled in with the default value and then I can delete it to set it to blank?
    • panels 2 has the default title greyed out, with a checkbox to override - would be nice to have here as well [catch]
    • Excellent idea. The current situation makes you wonder what the default title is. Using his suggestion we could leave out the description all together. [gaele]
    • Great idea @DONE: search/create patch/issue to do as gaele said B/
  • The fieldset and fieldset captions are redundant in this section
  • The labels for page-specific visibility might be: Show on these pages:, Don't show on these pages:, and Advanced*.
    • Beginning with "Show" or "Don't show" is a good idea. Something like "Show on only the listed pages." and "Don't show on the listed pages. Show on all other pages."? [elv]
    • See his labeling suggestion under "Post settings". The block configuration page has room for improvement too ("Page specific visibility settings": ugly language!). How about: Show block on these pages: All, except the listed ones / Only the listed ones. And how about: Users can control the display of this block: No / Yes, shown by default / Yes, hidden by default. I guess my point is: options should be short, clear, easily distinguishable. [gaele]
    • The 'page specific visibility settings' needs a makeover. Why can't you have show on pages foo/*, but hide on pages foo/bar, and only show if php code returns TRUE? I don't think there's any logical or technical reason, it's just a UI oversight. @TODO: make wireframe for the block configuration page, or at least the 'page specific visibility settings' fieldset B/
  • Notably when you collapse all fieldsets, no "default" options are available. This seems odd.
    • There are several places in drupal where this occurs. Usability Guidelines and Design Patterns could help here. B/

Menus

  • It's odd that the word list(s) has an optional es when menus is listed immediately after. Either this text should reflect the number of items in the list, or all plurals should show the optional es.
  • This should be removed from the description: Select an operation from the list to manage each menu or menu item. as no operations are visible.
    • This is leftover from the old menu page and @DONE: needs to be fixed in d6. B/
    • The issue for this is here: http://drupal.org/node/195083 [rowanw]

Add menu

  • Why should I Remember to enable the newly created block in the blocks administration page?
    • It's not trivial -- there are theme, region and weight selections to be made. Of course, we could offer the region and weight setting here for the default theme.
      • region, yes, the others don't make sense here. @DONE: add select list to optionally add the new menu's block to a region in the default front-end theme with weight 0 (d7) B/
      • #202854 [marco.robotangel]
    • In its current location the Remember... is easily overlooked. [gaele]
      • @DONE: move the 'remember...' text into the form-submit result page. Remove the 'Enter the name text entirely' B/
  • The menu name and title fields are reversed when compared with Blocks and other item creation interfaces.
    • @DONE: swap them. B/
    • Also: labels for human-readable and machine-readable names are not consistently used throughout Drupal. E.g. in in Add content type "Name" is the human-readable name. [gaele]
  • Typo in help text: This name may consist of only of lowercase letters, numbers, and hyphens, and must be unique. should be ''This name must consist of lowercase letters, numbers, and hyphens, and must be unique.
    • @DONE: fix this and submit patch B/
  • After adding the menu, it's not obvious how to add something to the menu. Provide a link beneath the Menu Items table to "add menu item"
    • @DONE: Add link to admin/build/menu-customize/menu-[NAME]/add on form-submit B/

Add menu item

  • Why is the menu path and title order reversed again?
    • @DONE: swap these B/
  • Parent Item shouldn't show on this page, as I was adding the Menu Item to a specific menu.
    • You still need a parent from that menu. [chx]
  • Weight shouldn't be on this page; instead visual ordering should happen on the menu's page.
  • A popup to link to an existing page might be useful (i.e. "create a link to an existing page").
    • Hmmmm. Not sure how this could work in the UI @TODO: wireframing needed B/
  • ugh...! Why aren't hyphens allowed?
    • Just tried and used a hyphen, it seems to works. [elv]
  • in testing, I could create menu items with paths like my-path, mypath or test. Why?

Modules

  • It seems like this page should emulate WordPress' plugins page for consistency between platforms; i.e. Change enabled from checkboxes to links -- it's easier to detect a problem with a single plugin than if you enable a whole bunch at once.
    • No way! image enabling cck/views/devel modules one by one! yikes! Or "this isn't wordpress". [catch]
    • Lol! Agree. Although asynchronous-enabling could work. B/
  • Cron should run automatically here; why doesn't it?
    • Why...? [chx]
    • @chx - I don't think it's clear that cron needs to run every hour and not just once [dmitrig01]
    • @chx - Why? Because "Update Status" displays a message with something about cron (update must have cron run to display available updates) and people may think that it is related to module administration as a whole. [José San Martin]
    • @DONE: run cron once when install.php has done it's thing (by including an image with src="/cron.php" or similar method) B/
  • Core - optional and Core - Required seems odd... why not hide the Required modules and simply list the modules configurable modules?
    • Eaton has raised this already in IRC, I agree. You can't do anything with the required modules, why not make them #value. [chx]
    • yes, good plan [catch]
    • See http://drupal.org/node/195859
  • Updates should be announced inline (see WordPress 2.3)
    • http://drupal.org/node/197486
    • @DONE: now that update status is in core it makes sense to merge modules and update status pages and data. search/create issue/patch for this B/
  • I shouldn't be told after enabling modules that no newer versions are available; whenever I visit this page, I should be shown what's updates are available with download or automatic update links.
    • Is there any reason not to run update status on disabled modules? @DONE: search/create issue/patch B/
      • #162788 - this seems to be an issue for quite a long time now... [marco.robotangel]
  • Throttle seems problematic here -- not that it shouldn't be offered, but that it should be on by default.
    • See my comment on block throttle: I disagree. [chx]
    • again, imagine the support requests if we did this, shudders [catch]
  • As part of the success messages, it would be nice if it listed things like "new permissions are available for Module X" rather than forcing me to click on the opaque permissions link.
    • @TODO: get adminrole.module (or similar functionality) in core for drupal7 B/
    • @TODO: create wireframes for including perms-setting in the module-enabling process (d7) B/
  • There should be an option to auto-enable required modules (i.e. Locale and Content translation modules)
    • Last I checked, the dependency checker worked. So, huh? [chx]
    • I think he means javascript selection of dependencies or something, or auto-enable on submit with aptitude styles message to let you know
      • @DONE: This feature would eliminate any doubt the user might have about dependency-enforcement/management. Which currently is not clear, as Chris demonstrates B/
  • Module uninstallation seems janky. Why not just delete from the modules directory? I don't understand this; not to mention that no modules were available for uninstallation. What might be more useful is a reset module which would clear the DB of settings and related data.
    • Apache must not be able to write modules directory. Clearing the database is not trivial, if the module does not offer hook_uninstall, there is nothing Drupal can do. [chx]
    • @chx - I think it's unclear that you need to disable to un-install, and disabling doesn't delete content or anything like that
    • **@TODO: improve the help text on the uninstall page. Possibly also on the main module page, eg "If you disable a module, check whether it needs uninstalling". OR EVEN BETTER -- when you disable a module, get a message saying "This module made changes to the database. If you want to completely remove it, go to Uninstall". Some handbook material on installing/uninstalling modules would be good too. I've just had a quick glance at the main handbook page on drupal.org and couldn't immediately find anything.... -- joachim

Themes

  • again, showing updates inline would be preferred.
  • default is a weird name for the option... I understand the option, but perhaps it should be use this theme and a checkbox option to allow people to override the default theme?
    • This page needs a makeover; The checkboxes to enable and radio buttons for default are too far apart. They should be in the left-most columns (like modules page) and closer together. But the thumbnail image sets the row-height. Maybe two pages are needed; one for list of themes, thumbnails and 'enable' (like modules page) and another for links to 'configure', and to set the 'default'. @TODO: create wireframes for themes page/s B/

Global Settings

  • wow, that's a lot of text.
  • why are these fieldsets not collapsible?
    • @DONE: make shortcut icon and logo fieldsets collapsible and collapsed. They are not frequently adjusted. B/
  • Site slogan should be set during installation if it's offered here.
    • Or not. [chx]
    • Too many options during install is a bad thing, in my opinion. [Liam McDermott]

Theme Configuration

  • the lock color icons are misaligned in Safari
  • why are these fieldsets not collapsible?
    • @DONE: as above B/
  • There should be some suggestions for creating the logo -- especially size suggestions... i.e. the shortcut icon should be 16x16 pixels.
    • @DONE: add help text about shortcut icon size, and transparency in logo image B/

Site Configuration

  • Why is the menu repeated in the content and in the sidebar? Seems unnecessarily duplicative.
    • Because the content can show descriptions and can show icons if so themed. [chx]
    • A page that exists just to show icons? That doesn't convince me. The descriptions are helpful though. [gaele]
  • Administration Theme... yay! On by default plz can has?
    • On? There is no on setting here. [chx]
    • In the usability group there was discussion about creating an admin theme in core for D7. This could be the default. [gaele]
    • NO. The administrative theme can be an abrupt interruption in an otherwise seamless experience on a site. [sepeck]
      • So can long forms that are tedious to scroll, and cumbersome UIs that can't be enhanced because of the theme-limitations! :) B/
      • To quote others - This is Drupal. Drupal is complex and has lots of options. Once configured most users will not see huge forms, merely what they have rights to see. Removing options under the 'it must be simple because people are too' mantra is silly. [sepeck]
  • Kind of dumb that I have to manually enable Blog APIs after enabling the module...!
    • Only if you use a third party blogging software, otherwise it is useless. Off by default reduces later issues. [sepeck]
    • @DONE: enhance module descriptions and help text to clarify when blog.module and blog api modules are needed B/
  • A lot of good stuff is in here that I think should be bubbled up; I don't have time to get into these now...
    • That's a shame. :( You're feedback is very valuable! Thank you so much! B/

Usability

Group organizers

Group categories

UX topics

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: