I would like to see a formal, written document which outlines the design practices to adhere to when writing modules for CMSMS. This is to ensure a better, more consistent user experience.
For example, the document would include instructions on:
* Where buttons are to be placed in relation to tables (above or below, or both)
* Where buttons are to be placed in relation to forms (above or below, or both)
* Where bulk action checkboxes are to be placed in relation to lists/tables (left or right)
* Where bulk action buttons are to be placed (bottom right, top right, bottom left, top left, combination)
* Which heading styles (h1, h2, h3 etc) to use in various positions on the page
* Labels for standard buttons (Submit, Apply, Cancel)
* Labels for tabs (Articles vs Items, Settings vs Preferences, etc)
* Table sorting capabilities/icons
* Position of tips/help text per page (above heading, below heading, tooltip/icon)
* Icons (many modules come with their own and it would be good to offer more standardised options)
I feel this would make using CMS Made Simple a much smoother experience for users and developers alike. I'm more than happy to contribute to, or project manage, such a document.
Design consistency
-
calguy1000
- Support Guru
- Posts: 8169
- Joined: Tue Oct 19, 2004 6:44 pm
Re: Design consistency
I am hesitant to write, and especially to enforce a 'style guide' of any sort on CMSMS module developers.
Though we have certainly seen some really good examples of why a style guide should be enforced, there haven't been that many of them, and the really bad projects are dying off (if they haven't died off already).
Additionally, with any design style guide there are always numerous exceptions to almost every rule. As well, once you have a style guide you need to continue to evolve it to meet new technologies or new ideas. it becomes yet another project to manage. Also you have to consider things like RTL languages or vertically oriented languages.
I regularly see new features, or techniques or 'ways of laying out pages' that i will sooner or later implement in my cmsms modules.
I can only state the ways I "usually" (though not always) develop my admin templates.
Q: Where buttons are to be placed in relation to tables (above or below, or both)
A: Till now I have tended to place the buttons/links below the table, unless the table could get huge, in which case I would place them both above and below. Though I think I will reverse this idea going forward.
Q: Where buttons are to be placed in relation to forms (above or below, or both)
A: Same as the above question. I used to place them below, but now I am tending to try to place buttons at the top of the form. This is both because of potentially long forms, and the fact that users tend to make one or two quick changes and hit submit so i want to try to favour that.
Q: Where bulk action checkboxes are to be placed in relation to lists/tables (left or right)
A: I usually try to place these on the right, but there are times when I can see having them on the left would be intelligent.
Q: Where bulk action buttons are to be placed (bottom right, top right, bottom left, top left, combination)
A: I usually try to place these on the bottom right.... but again, there may be times when placing them on the top left would be appropriate.
Q: Which heading styles (h1, h2, h3 etc) to use in various positions on the page
A: The CMSMS Admin theme uses the H1 and H2 tags IIRC, so I usually place the title of my action in an h3 tag. I try to prefer fieldsets and legends over h4 tags etc. Unless i'm on a help page.
I use <div class="pagewarning"> (I think that's it).. to display a warning in a page
I use <div class="information"> to display informational text
When building form elements I try to use:
<div class="pageoverflow">
<p class="pagetext">{* the prompt for the field *}</p>
<p class="pageinput">
{* the input field *}
[<br/>{* optional help text *}]
</p>
</div>
For tables:
<table class="pagetable">
<th class="pageicon"> for table columns that will hold an icon
Q: Labels for standard buttons (Submit, Apply, Cancel)
A: I try to use "Submit", "Apply", "Cancel", "Next", "Prev", "Forward", "Back", "Filter", "Reset"
but these are all translatable, and only a loose guideline. It doesn't make sense for example to have 2 "Submit" buttons on what appears to the user to be a single form that do two different things.
Q: Table sorting capabilities/icons
A: I have played around with tablesorter plugin (provided in the JQueryTools module). but am still not completely happy with the way this works yet, so I won't comment on that at this time.
Q: Position of tips/help text per page (above heading, below heading, tooltip/icon)
A: Here, it depends on what is on the page. Sometimes it makes sense to provide help for the entire page at the top of the page, sometimes I may provide one or more information sections below headers.
In 2.0 we're moving to alot of popup help icons. These will either be beside the input element, or it's prompt/label. I'm also trying to make sure that each table header has a title field, Each link in a table cell has a title field, and to use alot more tooltips
Q: Icons (many modules come with their own and it would be good to offer more standardised options)
A: Here I have to both agree and disagree.. Sometimes there is a need for an icon that I think should be included in the admin theme because it's relatively common (for me, or my modules).... but I also don't want the admin themes to have to maintain hundreds of icons that aren't often used. And I certainly don't want to have to maintain a project for just named icons.
Though we have certainly seen some really good examples of why a style guide should be enforced, there haven't been that many of them, and the really bad projects are dying off (if they haven't died off already).
Additionally, with any design style guide there are always numerous exceptions to almost every rule. As well, once you have a style guide you need to continue to evolve it to meet new technologies or new ideas. it becomes yet another project to manage. Also you have to consider things like RTL languages or vertically oriented languages.
I regularly see new features, or techniques or 'ways of laying out pages' that i will sooner or later implement in my cmsms modules.
I can only state the ways I "usually" (though not always) develop my admin templates.
Q: Where buttons are to be placed in relation to tables (above or below, or both)
A: Till now I have tended to place the buttons/links below the table, unless the table could get huge, in which case I would place them both above and below. Though I think I will reverse this idea going forward.
Q: Where buttons are to be placed in relation to forms (above or below, or both)
A: Same as the above question. I used to place them below, but now I am tending to try to place buttons at the top of the form. This is both because of potentially long forms, and the fact that users tend to make one or two quick changes and hit submit so i want to try to favour that.
Q: Where bulk action checkboxes are to be placed in relation to lists/tables (left or right)
A: I usually try to place these on the right, but there are times when I can see having them on the left would be intelligent.
Q: Where bulk action buttons are to be placed (bottom right, top right, bottom left, top left, combination)
A: I usually try to place these on the bottom right.... but again, there may be times when placing them on the top left would be appropriate.
Q: Which heading styles (h1, h2, h3 etc) to use in various positions on the page
A: The CMSMS Admin theme uses the H1 and H2 tags IIRC, so I usually place the title of my action in an h3 tag. I try to prefer fieldsets and legends over h4 tags etc. Unless i'm on a help page.
I use <div class="pagewarning"> (I think that's it).. to display a warning in a page
I use <div class="information"> to display informational text
When building form elements I try to use:
<div class="pageoverflow">
<p class="pagetext">{* the prompt for the field *}</p>
<p class="pageinput">
{* the input field *}
[<br/>{* optional help text *}]
</p>
</div>
For tables:
<table class="pagetable">
<th class="pageicon"> for table columns that will hold an icon
Q: Labels for standard buttons (Submit, Apply, Cancel)
A: I try to use "Submit", "Apply", "Cancel", "Next", "Prev", "Forward", "Back", "Filter", "Reset"
but these are all translatable, and only a loose guideline. It doesn't make sense for example to have 2 "Submit" buttons on what appears to the user to be a single form that do two different things.
Q: Table sorting capabilities/icons
A: I have played around with tablesorter plugin (provided in the JQueryTools module). but am still not completely happy with the way this works yet, so I won't comment on that at this time.
Q: Position of tips/help text per page (above heading, below heading, tooltip/icon)
A: Here, it depends on what is on the page. Sometimes it makes sense to provide help for the entire page at the top of the page, sometimes I may provide one or more information sections below headers.
In 2.0 we're moving to alot of popup help icons. These will either be beside the input element, or it's prompt/label. I'm also trying to make sure that each table header has a title field, Each link in a table cell has a title field, and to use alot more tooltips
Q: Icons (many modules come with their own and it would be good to offer more standardised options)
A: Here I have to both agree and disagree.. Sometimes there is a need for an icon that I think should be included in the admin theme because it's relatively common (for me, or my modules).... but I also don't want the admin themes to have to maintain hundreds of icons that aren't often used. And I certainly don't want to have to maintain a project for just named icons.
Follow me on twitter
Please post system information from "Extensions >> System Information" (there is a bbcode option) on all posts asking for assistance.
--------------------
If you can't bother explaining your problem well, you shouldn't expect much in the way of assistance.
Please post system information from "Extensions >> System Information" (there is a bbcode option) on all posts asking for assistance.
--------------------
If you can't bother explaining your problem well, you shouldn't expect much in the way of assistance.
-
gocreative
- Power Poster
- Posts: 265
- Joined: Mon Mar 14, 2011 1:16 am
Re: Design consistency
Thanks for the thorough reply to my suggestion.
In my view, I believe it's quite important to have, at the very least, a simple guideline (whether it's enforced is another story). For example, you mentioned you used to place buttons at the bottom of tables but now prefer the top. That's one example where a simple guidline such as "All buttons/links should appear both above and below the content" would suffice. It's clear enough, unlikely to change over time, and gives developers an idea of what they at least should be doing.
Similarly, some modules use "Apply" while others use "Save and Continue Editing", which I know first-hand is confusing for both myself and my clients. This would be written as simply as "Buttons which save the current data without leaving the page should be labelled 'Apply'". It's mainly these types of things that I think could do with a few pointers.
I won't bother going through all of the other points because they were just off the top of my head and your responses are fine, but just with regard to icons, in my experience I think adding about 15 common icons to the current set would be more than sufficient for most modules.
Anyway, just my suggestion and as I mentioned I'm happy to assist putting something very basic together for further feedback, if you decide it's worthwhile. Thanks.
In my view, I believe it's quite important to have, at the very least, a simple guideline (whether it's enforced is another story). For example, you mentioned you used to place buttons at the bottom of tables but now prefer the top. That's one example where a simple guidline such as "All buttons/links should appear both above and below the content" would suffice. It's clear enough, unlikely to change over time, and gives developers an idea of what they at least should be doing.
Similarly, some modules use "Apply" while others use "Save and Continue Editing", which I know first-hand is confusing for both myself and my clients. This would be written as simply as "Buttons which save the current data without leaving the page should be labelled 'Apply'". It's mainly these types of things that I think could do with a few pointers.
I won't bother going through all of the other points because they were just off the top of my head and your responses are fine, but just with regard to icons, in my experience I think adding about 15 common icons to the current set would be more than sufficient for most modules.
Anyway, just my suggestion and as I mentioned I'm happy to assist putting something very basic together for further feedback, if you decide it's worthwhile. Thanks.
