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

[Shaun M. <sh...@ae...>]

On 4 Jan 2005, at 23:47, Wendall Cada wrote:
> 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.
>

Does the current 'no items in the list' message come from the module or 
from the core list class? If it came from the core, then that's one 
problem solved.

>
> 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.
>

I've tried, many times to come up with aligned css forms and 
ultimately, they fail on particular browsers (IE usually) when they get 
to a particular complexity or if the label/entry is of dissimilar 
sizes. My favourite is using definition lists (DL) but they don't 
render on some browsers if the label is more lines than the entryfield 
alongside, and you're stuck with simple forms too.

Witness menuman's advanced form and try and replicated that in css, not 
that that is a good idea though as that interface is by far the worst 
in phpwebsite.

We should also make more use of fieldset and legend as well even though 
they don't render so well on IE. And label has to be used more also for 
xhtml compliance.


> 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.
>

If there were more core styles then you wouldn't need so much module 
css. No offence intended Wendall but there's nothing in phpwsRSSfeeds 
that shouldn't be in the core styles - it's just boxes, menus and lists 
after all, and those are used everywhere. By putting them in the module 
it makes it really hard for theme developers to make the layout 
consistent across modules.


>> Buttons
>
> 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.
>

Centering is usually one of the things I take out wherever I can. 
Alignment is language specific so leaving it out is usually the best 
option and trusting the users browser to align things correctly. 
English may be left-to-right but there are plenty of languages that 
aren't. Perhaps centering is the politically correct method. (joking) 
;-)

>> 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.
>

I'd agree here too. In showing someone how pagemaster worked a while 
back, the multiple buttons at the bottom of the page with menu choices 
and save page confused the hell out of them and that's just one 
example.

Shaun
aegis design - http://www.aegisdesign.co.uk