Re: [Phpwebsite-developers] Defining and implementing design standards in phpWebSite

[Wendall C. <wen...@to...>]

Very good article Michael. I'll add my comments on top of Matt's since I
agree with most of his comments and add my own observations.

> Titles
> -------------------
> Currently I am using the Control Panel (which is pure line item CSS)
> wrapped around each of my modules.
> 
> I like this format because:
> 1) You don't have to click on Control Panel every time you want to go
>    to another module. Just click back on Content. 
> 
> 2) It allows us to have the same options on every page in the same
>    place.
> 
> 3) It eliminates the Back to Main junk. The tabs always take you where
>    you want to go.
> 
I have used this system helping with some testing for Matt. It increases
the usability of the control panel incredibly.  It is very expandable
and easy to navigate. It addresses many concerns about consistency since
it wraps all administrative stuff with a common interface.

> In reference to the Add [something], Edit [something], etc. In all my
> new modules 'New' is used to create a new item. I think all my mods
> have that same tab and I would support use of this word for English
> modules. We can discuss whether 'New', 'Create', or 'Add' is the
> better word and whether the name of the item should be suffixed to the
> command.

I don't have any recommendations on English words for basic stuff, but
 we do need to decide on wording for add, save, update, view, edit,
 delete, show, hide, settings, etc. And these should be consistent
 across modules.

*Side Note: It would be nice if Matt added recommendations for
consistent function naming for these in the module creation guide.

> I would also like to agree on a standard for the listing of items. I
> am using Archive in Blog and List in Categories. We can agree on a
> standard for this tab. For editing and deleting however, those options
> are listed along with the items. When chosen, the edit form opens
> within the List tab. 

It would be nice to use the same list for everything. However, the list
does need to be flexible enough to accommodate all uses. For example,
what if I wanted to do list sorting. Not just sort the display order,
but actually change entry order in the database. Currently, there is no
method to do this and List is too inflexible to really allow this. Also,
I wanted to create a list that used different text parsing for a field,
so the only way to change it currently was to create my own List, which
is just a copy of List.php with modifications. I'd like to get away from
that sort of thing entirely. Steven and I have discussed this quite a
bit and I feel it will be resolved in 1.0, so I'm not too worried, just
wanted to give some examples. I don't necessarily think that List should
include everything and the kitchen sink for what just a few mods would
use, but I do think it should be flexible enough to do anything
necessary with the list that is required for the mod, without forcing
the developer to use another List lib. From a layout perspective, I
fully agree that some of the columns need to be fixed and others float. 

> Lists
> ----------------------------
> For empty lists, I vote for showing the column headings basically
> because the DBPager (a new listing class for 1.x) works well with this
> option. Also, DBPager uses only one template file.
> 
Maybe a default message advising the user that there are no items
available for view currently. This leads into another subject, but it
might be nice to have a nice list of canned English phrases for use.
This would come in handy for me. I am sure for those who English isn't
their first language, a list of standardized phrases would be useful as
well.

> Input
> ----------------------
> I have no problem with the first form style:
> 
> Name
> _____________
> |            
> 
> Address
> _____________
> |
> 
> I will say, however that the grid format is, imho, easier to
> navigate. I will leave this open to debate. I could go either way.
> 
> I agree with no background color, no enumeration, no colons,
> and no emphasis on the form labels.

I tried to implement an experimental tableless grid layout in the
phpwsRSSFeeds admin side of things. I know it has problems, and I fully
agree with the recommendations in the article. I also have no problem
with the first form style, assuming that the form is very simple. Once
the interface becomes more complex, it is hard to use many other styles
other than the grid style. I think that some sample forms should be put
together to illustrate some real life examples. I have no problem
implementing any ideas into rssfeeds for testing and feedback if someone
wants to point out changes.

Major problem in implementation for phpwsRSSFeeds was a lack of core
styles to build on and no full support for module level css. I believe
that these have already been addressed in large by Matt in 1.0.

> Checkboxes
> ----------------------
> I agree with everything here. Checkboxes should be placed before
> statement phrased as a question.
> 
> I also agree with only using checkboxes for boolean questions.

I agree here as well.

> 
> Buttons
> ---------------------
> I tend to prefer the button being set flush to the left. Because forms
> are often in a table, I like dropping the submit button after the
> closing of the table. The second example puts the button in the second
> column of a half completed row. I don't like that.

I tend to drop the button after the closing of the table as well.
However, I usually make the button centered. I do however agree that
flush left may be better. This may depend on what the grid layout is
like. For instance, if my text labels are right justify, and my input
fields are left justify, centering may make sense, as it follows layout.
However, I see no problem using left justify for everything.

> Buttons as links
> --------------------
> Agree 100%. Anything that does not pass form elements, doesn't need
> to be in a button.

Another point of note on this item. If an item does need to pass form
elements, but needs some type of user interaction, I'd like to see the
javascript popup dropped from use. A standardized form for user
confirmation would be very nice to have. Maybe as a part of Form.  

Another comment on the subject of forms. In the button example, there
are a couple samples of multiple forms on the same admin page. I'd like
to see this go away if possible. I made some of my own functions for
addition of fatcat categories in phpwsRSSFeeds so that the form elements
could be included in the item creation and editing forms, instead of an
additional form at the bottom of the page.

Wendall