phpwebsite-developers

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

[<po...@mi...>]

Hi all,

I have written an article about defining and implementing design =
standards
in phpWebSite. I want to address some of the inconsistency in the =
interface,
focusing on usability rather than the actual html code.

I believe that a design standard, with examples and guidelines, will =
benefit
on the quality of the html code.
The article is not meant to be the design standard, merely to give some
inspiration, and most important of all, to give some input for a debate =
on
the subject.

If you have the time and interests, please look at the article. Feel =
free to
comment the article directly on the website.

Link to the article:
http://www.michaelshjemmeside.dk/index.php?module=3Dpagemaster&PAGE_user_=
op=3Dvi
ew_page&PAGE_id=3D7

Please be patient while loading the article. My ISP is V-E-R-Y slow from
time to time. It could take up to several minutes before the page is =
loaded.

Another warning - besides the article, the website is in Danish. Please =
do
not get lost :-)

- Michael Rasmussen (TechElephant)

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

[Matthew M. <ma...@tu...>]

Thanks for the write up. I saw this kind of late in the day so I will
read more about it tomorrow.

Also, please take a look at 1.0.0 alpha code if you have a chance. We
are trying to take the road you are pointing us down. It currently uses
a tableless design and relies on CSS more than its predecessor. Stay
with us as we move forward and make sure to come by the chat room.

P.S. I am close to getting 0.x modules working in the new core. Once I
do, I will update the demo.

~ Matt

On Mon, 2005-01-03 at 15:57, Michael H=C3=B8j Rasmussen wrote:
> Hi all,
>=20
> I have written an article about defining and implementing design standa=
rds
> in phpWebSite. I want to address some of the inconsistency in the inter=
face,
> focusing on usability rather than the actual html code.
>=20
> I believe that a design standard, with examples and guidelines, will be=
nefit
> on the quality of the html code.
> The article is not meant to be the design standard, merely to give some
> inspiration, and most important of all, to give some input for a debate=
 on
> the subject.
>=20
> If you have the time and interests, please look at the article. Feel fr=
ee to
> comment the article directly on the website.
>=20
> Link to the article:
> http://www.michaelshjemmeside.dk/index.php?module=3Dpagemaster&PAGE_use=
r_op=3Dvi
> ew_page&PAGE_id=3D7
>=20
> Please be patient while loading the article. My ISP is V-E-R-Y slow fro=
m
> time to time. It could take up to several minutes before the page is lo=
aded.
>=20
> Another warning - besides the article, the website is in Danish. Please=
 do
> not get lost :-)
>=20
> - Michael Rasmussen (TechElephant)
>=20
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
--=20
Matthew McNaney
Internet Systems Architect
Electronic Student Services
Appalachian State University
Phone: 828-262-6493
http://phpwebsite.appstate.edu
http://ess.appstate.edu

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

[Ken N. <ke...@co...>]

I would like to jump on the bandwagon.  I believe Mike Noyes brought
this up a few months ago and there was some discussion about CSS
methodology / standards, but no real consensus.

How many times has a module's "theme" clashed with that of the main
theme?  Where colors were hard-coded in the module instead of defaulting
to the theme?

Just recently I perused the Xaraya site to compare and contrast their
efforts with that of phpWebSite.  I found two items which I believe
"should" be incorporated into phpWebSite.

The first is CSS methodology.  Everyone writes code differently...
accomplishing the same results.  Xaraya set up mandatory default CSS
classes:

http://www.xaraya.com/documentation/rfcs/rfc0010.html#rfc.section.2

Establishing standards enables modules to work within the theme instead
of independent of the theme.

Second, here is a "how-to" Xaraya doc for module / theme
interdependence.

http://xaraya.org/index.php/documentation/229

I would also like to add theme "columnization" to the list on Michael's
page.  How many default columns "should" there be?  Can phpWebSite's
Layout module seamlessly handle three / two / one column themes?  What
methodology can be used for those columns?  (left - middle/center -
right) or (left - main - right) or some other variation?

Again, count me in on CSS standardization and I am willing to do any
grunt work necessary.

Ken

On Mon, 2005-01-03 at 15:57, Michael H=C3=B8j Rasmussen wrote:
> Hi all,
>=20
> I have written an article about defining and implementing design standa=
rds
> in phpWebSite. I want to address some of the inconsistency in the inter=
face,
> focusing on usability rather than the actual html code.
>=20
> I believe that a design standard, with examples and guidelines, will be=
nefit
> on the quality of the html code.
> The article is not meant to be the design standard, merely to give some
> inspiration, and most important of all, to give some input for a debate=
 on
> the subject.
>=20
> If you have the time and interests, please look at the article. Feel fr=
ee to
> comment the article directly on the website.
>=20
> Link to the article:
> http://www.michaelshjemmeside.dk/index.php?module=3Dpagemaster&PAGE_use=
r_op=3Dvi
> ew_page&PAGE_id=3D7
>=20
> Please be patient while loading the article. My ISP is V-E-R-Y slow fro=
m
> time to time. It could take up to several minutes before the page is lo=
aded.
>=20
> Another warning - besides the article, the website is in Danish. Please=
 do
> not get lost :-)
>=20
> - Michael Rasmussen (TechElephant)
>=20
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
--=20
Ken Nordquist
"Community Marketing for the Next Generation"
Call Us Toll Free: 866-621-4043
http://communitygems.com

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

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

On 4 Jan 2005, at 03:09, Ken Nordquist wrote:
> How many times has a module's "theme" clashed with that of the main
> theme?  Where colors were hard-coded in the module instead of 
> defaulting
> to the theme?
>

That's another area that peeves me. Error messages are often hardcoded 
colours in some modules. IIRC there's a function call for displaying 
errors in the core already but it's rarely used. And IIRC there's a 
PEAR error message system too.

> I would also like to add theme "columnization" to the list on Michael's
> page.  How many default columns "should" there be?  Can phpWebSite's
> Layout module seamlessly handle three / two / one column themes?  What
> methodology can be used for those columns?  (left - middle/center -
> right) or (left - main - right) or some other variation?

That's another one. I'd hope that the new layout engine just completely 
drops the column thing and allows completely arbitrary areas on the 
page in which blocks can be placed, with blocks that have no 'home' 
defaulting to the bottom of the page perhaps rather than disappearing 
into oblivion if your theme.tpl doesn't have that area defined. Instead 
of the left/right arrows in layout for moving the block between 
columns, you just have a pulldown list of the block names in which you 
want to move it.

>
> Again, count me in on CSS standardization and I am willing to do any
> grunt work necessary.

Ditto. Alas, I think this should be addressed mostly at the php/design 
level, not perhaps the css/.tpl level. But, usability design is 
something that can be done without any coding skills.

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

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

[Matthew M. <ma...@tu...>]

> I would also like to add theme "columnization" to the list on Michael's
> page.  How many default columns "should" there be?  Can phpWebSite's
> Layout module seamlessly handle three / two / one column themes?  What
> methodology can be used for those columns?  (left - middle/center -
> right) or (left - main - right) or some other variation?

for 1.x I am developing with just two major tags/columns and 2 minor.

BODY - Unless defined otherwise, content will appear here.
SIDEPANEL - smaller boxes usually are here

The minors are HEADER and FOOTER. They are used by the Layout module,
but are not required.

Other than that you can add as many other areas as you want, in any
structure that you want.

-- 
Matthew McNaney
Internet Systems Architect
Electronic Student Services
Appalachian State University
Phone: 828-262-6493
http://phpwebsite.appstate.edu
http://ess.appstate.edu

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

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

On 4 Jan 2005, at 18:42, Matthew McNaney wrote:
>
> for 1.x I am developing with just two major tags/columns and 2 minor.
>
> BODY - Unless defined otherwise, content will appear here.
> SIDEPANEL - smaller boxes usually are here
>
> The minors are HEADER and FOOTER. They are used by the Layout module,
> but are not required.
>

Hooray - always thought those were odd things to miss out.

> Other than that you can add as many other areas as you want, in any
> structure that you want.

Whilst we're on the subject of Layout, is there anything on the radar 
for allowing more than one theme.tpl (or whatever the basic structure 
file is) where an admin gets to pick a different one depending on a 
module/pagemaster page/category.

eg. Say I wanted a 3 column links page but just BODY for a pagemaster 
page.

Currently, it's quite a bit of work, and not entirely optimal to hack 
around the one theme.tpl limit using theme.php and a couple of module 
hacks to allow more specific menuman/block positioning. I really want 
to get away from the nuke-esque feel sometimes on some sites.

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

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

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

That's a particularly well observed and informed article Michael.

Some of the issues are being addressed in the new code the team are 
working on. I think we've beaten them on the head enough times in IRC 
about menus at least, and we've had long ranging discussions about CSS 
and how it should be implemented - which I don't entirely agree with. 
Ken noted two links to Xaraya and IMHO they've got the mix right there, 
enforcing some classes without making it overly complex. I just hope 
the 3-tier css method we've chose can largely be ignored at a module 
level and module developers don't try and cram fancy layout in their 
module css. Otherwise we're back to inconsistent look and feel across 
modules.

I hope the team have a good look through the article, and the Xaraya 
ones, and think how they can be addressed.

Personally, I'd like to see more support functions for module 
developers that let them produce menus, submenus, lists, links etc to a 
standard rather than having to build them up manually either in the 
code or in a template. That way there's a set method of doing it that 
can be styled globally. Ie. that we make more use of the box_style type 
of method and expand it to lists, menus, links, tabbed menus with 
appropriate css too... It just appears mad to me that I have to edit 
multiple templates to change the look of menus across a site, if I can 
at all.

So, well done for putting it all together Michael.

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

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

[<po...@mi...>]

Thanks for your reply Shaun. It is highly appreciated.

> Some of the issues are being addressed in the new code the team are
> working on. I think we've beaten them on the head enough times in IRC
> about menus at least, and we've had long ranging discussions about CSS
> and how it should be implemented - which I don't entirely agree with.

I know. I have been following all of those discussions with great interest.
It was my attention to participate in the discussion earlier, mainly in the
CSS thread, but I though you did okay without my interference :-)

> Personally, I'd like to see more support functions for module
> developers that let them produce menus, submenus, lists, links etc to a
> standard rather than having to build them up manually either in the
> code or in a template. That way there's a set method of doing it that
> can be styled globally.

I agree with you, and think we should focus on this issue when the time is
right. Functions helping the developers produce interface related content,
would ensure a consistent design. There might be a performance issue here,
but I will leave that up to the experts to find the right balance between
functions, templates and homemade implementations.

- Michael

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

[Matthew M. <ma...@tu...>]

> That's another one. I'd hope that the new layout engine just completely 
> drops the column thing and allows completely arbitrary areas on the 
> page in which blocks can be placed, with blocks that have no 'home' 
> defaulting to the bottom of the page perhaps rather than disappearing 
> into oblivion if your theme.tpl doesn't have that area defined. Instead 
> of the left/right arrows in layout for moving the block between 
> columns, you just have a pulldown list of the block names in which you 
> want to move it.

That is how it works, except the lost item is put in the BODY tag.

-- 
Matthew McNaney
Internet Systems Architect
Electronic Student Services
Appalachian State University
Phone: 828-262-6493
http://phpwebsite.appstate.edu
http://ess.appstate.edu

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

[Matthew M. <ma...@tu...>]

After reading Michaels Hjemmeside's article, here are my thoughts and
suggestions as they apply to 1.x. Some of these points will make more
sense when I can get a demo running.

Titles
-------------------
Currently I am using the Control Panel (which is pure line item CSS)
wrapped around each of my modules.

Looks something like the following

----------- ------------------
| Content | | Administration |
|         ---------------------------------------
|                                               |
|  [pic] Blog   [pic]Categories                 |


Once you get into a module, like Blog, you see this:

----------- ------------------
| Content | | Administration |
|         ---------------------------------------
|                                               |
| -------- -----------                          |
| | New  | | Archive |                          |
| |      -------------------------------------- |
| |                                           | |
| | NEW BLOG ENTRY                            | |
| | [form]                                    | |


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.

As for what is contained IN the embedded panel, it's template looks
like this:

<h1>{TITLE}</h1>
{CONTENT}

This template houses all administration done within the module.
The control panel is common. You CAN have your own control panel for
your module, but I am opting not to.

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


Submenus
----------------------------
I think this is covered by the Control Panel method.


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.

Pattern
--------------------------
I would say most lists will look like the first example. All the
options for an item should appear together and to the extreme
right. If there are too many options per item, icons can be
substituted.

Also the second example is from Users, which has its own
listing class. Hopefully, we can get everyone to use the one listing
class in 1.x. 

Narrow Lists
-------------------------
Menu is an old module and its interface is definitely clunky. I think
we can steer clear of such things in the future.


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.


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.


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.

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


Tabbed Navigation
--------------------
See Control Panel info above. This has been implemented in 1.x. and
the class is easily accessible by other modules.


Tree Lists
-------------------
Agree here as well. Lists should be lists, not tables.



Conclusion
-------------------
I appreciate Michaels information. In our defense, many of the
examples are from older modules. We have learned a lot about CSS,
organization, interface, etc. since they were written years ago.

Since 1.x is getting closer to release, we have the opportunity to set
new guidelines benefiting developers and users alike.

Thanks,
Matt


-- 
Matthew McNaney
Internet Systems Architect
Electronic Student Services
Appalachian State University
Phone: 828-262-6493
http://phpwebsite.appstate.edu
http://ess.appstate.edu

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

[Mike N. <mh...@us...>]

On Tue, 2005-01-04 at 10:09, Matthew McNaney wrote:
> 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. 

Matt,
The one issue I have with the current fallout code is the core module
css is dynamic. It isn't always available for other modules to use, or
did I misunderstand something?

I think core css should be static and persistent; so module and theme
developers can utilize it, and build on it when necessary.

-- 
Mike Noyes <mhnoyes at users.sourceforge.net>
http://sourceforge.net/users/mhnoyes/
SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs

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

[Matthew M. <ma...@tu...>]

> Matt,
> The one issue I have with the current fallout code is the core module
> css is dynamic. It isn't always available for other modules to use, or
> did I misunderstand something?
> I think core css should be static and persistent; so module and theme
> developers can utilize it, and build on it when necessary.

I'm not sure if I am answering this correctly so get back to me here if
I am wrong.

What exactly should be persistent? Tables? Fonts? I'm not grilling you,
I just need my memory refreshed on this discussion as I know we have had
it before. It would benefit those who read this list to hear it anyway
so please expand upon your question.

thanks,
Matt

-- 
Matthew McNaney
Internet Systems Architect
Electronic Student Services
Appalachian State University
Phone: 828-262-6493
http://phpwebsite.appstate.edu
http://ess.appstate.edu

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

[Mike N. <mh...@us...>]

On Tue, 2005-01-04 at 13:37, Matthew McNaney wrote:
> > Matt,
> > The one issue I have with the current fallout code is the core module
> > css is dynamic. It isn't always available for other modules to use, or
> > did I misunderstand something?
> > I think core css should be static and persistent; so module and theme
> > developers can utilize it, and build on it when necessary.
> 
> I'm not sure if I am answering this correctly so get back to me here if
> I am wrong.
> 
> What exactly should be persistent? Tables? Fonts? I'm not grilling you,
> I just need my memory refreshed on this discussion as I know we have had
> it before. It would benefit those who read this list to hear it anyway
> so please expand upon your question.

Matt,
Core module css should always load in a persistent stylesheet. Currently
module css is loaded dynamically with @import and it's availability
isn't guaranteed.

Current example:
<style type="text/css"> @import url("./mod/controlpanel/templates/style.css"); </style>
<style type="text/css"> @import url("./themes/zen/templates/controlpanel/style.css"); </style>
<link rel="stylesheet"  href="./themes/zen/style.css" type="text/css" />

Proposed example:
<link rel="stylesheet" href="./core/style.css" type="text/css" />
<style type="text/css"> @import url("./mod/pagemaster/templates/style.css"); </style>
<link rel="stylesheet" href="./themes/zen/style.css" title="zen" type="text/css" />

css class reuse:
pagemaster mod wants to use the ????? class in controlpanel with a
slight modification. In the first case the modified css will only work
when controlpanel is active. In the proposal the controlpanel css is
always available for pagemaster to modify.

Does that make sense?

        Note: this is part of the reason I called for a single @import
        of loaded module css (controlled by boost) in the preferred
        stylesheet in my descendant selectors prof-of-concept.
        
        http://phpwebsite-comm.sourceforge.net/temp/

-- 
Mike Noyes <mhnoyes at users.sourceforge.net>
http://sourceforge.net/users/mhnoyes/
SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs

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

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

It would also have to have a template module css import as well. So 4 
style sheets. I do hope theme developers never have to modify anything 
other than the /themes/zen/style.css in this example and that the 
module css is largely free of fonts, colours, alignment and spacing 
unless it does something out of the ordinary for a good reason.

As long as you can change a class in /themes/zen/style.css and the look 
of the menu, or lists changes across all menus and lists then the 
solution works. If it doesn't change some module's look, then we've 
failed.


> Proposed example:
> <link rel="stylesheet" href="./core/style.css" type="text/css" />
> <style type="text/css"> @import 
> url("./mod/pagemaster/templates/style.css"); </style>
> <style type="text/css"> @import 
> url("./themes/zen/templates/controlpanel/style.css"); </style>
> <link rel="stylesheet" href="./themes/zen/style.css" title="zen" 
> type="text/css" />


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

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

[Mike N. <mh...@us...>]

On Wed, 2005-01-05 at 04:34, Shaun Murray wrote:
> It would also have to have a template module css import as well. So 4 
> style sheets. I do hope theme developers never have to modify anything 
> other than the /themes/zen/style.css in this example and that the 
> module css is largely free of fonts, colours, alignment and spacing 
> unless it does something out of the ordinary for a good reason.

Shaun,
Any class can be modified or overridden by the theme developer in
/themes/zen/style.css. The css cascade loads that last and it therefore
gets preferred status in the cascade.

> As long as you can change a class in /themes/zen/style.css and the look 
> of the menu, or lists changes across all menus and lists then the 
> solution works. If it doesn't change some module's look, then we've 
> failed.

Agreed.

        Note: I still believe in two external stylesheets with a single
        installed module @import. The static /conf/mod.css would be
        modified by boost on module install/uninstall. Core module css
        would load first. See my descendant selectors PoC. In addition
        alternate stylesheets are possible.
        
        http://phpwebsite-comm.sourceforge.net/temp/ <-- served as
        text/xhtml
        
        http://phpwebsite-comm.sourceforge.net/temp/xml.php <-- served
        as application/xhtml+xml


> > Proposed example:
> > <link rel="stylesheet" href="./core/style.css" type="text/css" />
> > <style type="text/css"> @import 
> > url("./mod/pagemaster/templates/style.css"); </style>
> > <style type="text/css"> @import 
> > url("./themes/zen/templates/controlpanel/style.css"); </style>
> > <link rel="stylesheet" href="./themes/zen/style.css" title="zen" 
> > type="text/css" />

-- 
Mike Noyes <mhnoyes at users.sourceforge.net>
http://sourceforge.net/users/mhnoyes/
SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs

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

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

On 5 Jan 2005, at 16:51, Mike Noyes wrote:

> On Wed, 2005-01-05 at 04:34, Shaun Murray wrote:
>> It would also have to have a template module css import as well. So 4
>> style sheets. I do hope theme developers never have to modify anything
>> other than the /themes/zen/style.css in this example and that the
>> module css is largely free of fonts, colours, alignment and spacing
>> unless it does something out of the ordinary for a good reason.
>
> Shaun,
> Any class can be modified or overridden by the theme developer in
> /themes/zen/style.css. The css cascade loads that last and it therefore
> gets preferred status in the cascade.

That's merely a bandaid over a self inflicted wound IMHO.

Perhaps I should clarify that with an example before donning my nomex 
pants.

phpwsRSSFeeds includes it's own module css to alter the look and feel 
of the menu from that of the system default (yes, I know we don't have 
one defined but go with me for now). As you say above, I could override 
that in /themes/zen/style.css or even in 
/themes/zen/templates/phpwsrssfeeds/module.css which would probably be 
a better place. Great. Fantastic. Powerful even.

However, that's merely masking the problem, that the module developer 
has chosen to override the system default. Personally, I'd rather edit 
the module css, removing the change, than patching over it in all my 
themes by introducing extra css in the themes themselves.

The problem then is that you have to either persuade the module 
developer to conform or continue patching module css every time they 
release a new version, just to make it look like the rest of the 
system.

This is the exact same situation we have with templates currently where 
the module developer has chosen to do something differently to the 
'standard'. The problem is, we've no 'standard' to which a module 
developer can conform to, and you can't slap wrists without one. 
Michael's article perhaps is a good start on one. We need to be much 
stricter on the UI otherwise my fear with the new css system will be 
the proliferation of admin across 100's of extra files just to strip 
out fancy css that shouldn't be there.

The module css and templates need to be as bland and generic as 
possible in order that they don't have to be overridden on a per module 
basis. It's also why I'm so hot for core functions/classes to produce 
most UI elements so that it's less likely a mod developer will roll 
their own.

How that is policed and by who might be interesting but it needs doing.


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

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

[Mike N. <mh...@us...>]

On Wed, 2005-01-05 at 09:58, Shaun Murray wrote:
> On 5 Jan 2005, at 16:51, Mike Noyes wrote:
> > On Wed, 2005-01-05 at 04:34, Shaun Murray wrote:
> >> It would also have to have a template module css import as well. So 4
> >> style sheets. I do hope theme developers never have to modify anything
> >> other than the /themes/zen/style.css in this example and that the
> >> module css is largely free of fonts, colours, alignment and spacing
> >> unless it does something out of the ordinary for a good reason.
> >
> > Any class can be modified or overridden by the theme developer in
> > /themes/zen/style.css. The css cascade loads that last and it therefore
> > gets preferred status in the cascade.
> 
> That's merely a bandaid over a self inflicted wound IMHO.

Shaun,
No it isn't. From my point of view, you are confusing the current
situation with what is being proposed for fallout.

> Perhaps I should clarify that with an example before donning my nomex 
> pants.
> 
> phpwsRSSFeeds includes it's own module css to alter the look and feel 
> of the menu from that of the system default (yes, I know we don't have 
> one defined but go with me for now). As you say above, I could override 
> that in /themes/zen/style.css or even in 
> /themes/zen/templates/phpwsrssfeeds/module.css which would probably be 
> a better place. Great. Fantastic. Powerful even.

Current phpwsrssfeeds css isn't relevant.

> However, that's merely masking the problem, that the module developer 
> has chosen to override the system default. Personally, I'd rather edit 
> the module css, removing the change, than patching over it in all my 
> themes by introducing extra css in the themes themselves.

The core css would only be extended by mod css in situations where a
needed class isn't defined. Theme developers should _never_ modify core
or module css directly.

> The problem then is that you have to either persuade the module 
> developer to conform or continue patching module css every time they 
> release a new version, just to make it look like the rest of the 
> system.

Yes. This is what core css is all about. Did I miss something?

> This is the exact same situation we have with templates currently where 
> the module developer has chosen to do something differently to the 
> 'standard'. The problem is, we've no 'standard' to which a module 
> developer can conform to, and you can't slap wrists without one. 
> Michael's article perhaps is a good start on one. We need to be much 
> stricter on the UI otherwise my fear with the new css system will be 
> the proliferation of admin across 100's of extra files just to strip 
> out fancy css that shouldn't be there.

No it isn't. The new system is very close to xaraya's implementation.
Don't look at 0.10.0 mod css as an indication of what will be in
fallout.

> The module css and templates need to be as bland and generic as 
> possible in order that they don't have to be overridden on a per module 
> basis. It's also why I'm so hot for core functions/classes to produce 
> most UI elements so that it's less likely a mod developer will roll 
> their own.

Agreed! We need to concentrate on this task. You'll see how the mod css
is beneficial as the process develops.

> How that is policed and by who might be interesting but it needs doing.

This goes in a coding standards doc, just like other projects. It isn't
complicated.

-- 
Mike Noyes <mhnoyes at users.sourceforge.net>
http://sourceforge.net/users/mhnoyes/
SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs

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

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

On 4 Jan 2005, at 21:29, Mike Noyes wrote:
>
>
> I think core css should be static and persistent; so module and theme
> developers can utilize it, and build on it when necessary.
>

Ditto that. Building your own css should be an extra above and beyond 
the core and module developers need a damn good reason to go their own 
way, or theme developers will be somewhat annoyed.

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

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

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

SV: [Phpwebsite-developers] Defining and implementing designstandards in phpWebSite

[<po...@mi...>]

Wendall, I will put my comments on top of yours, since I agree with you,
Matt, Mike, Shaun and Ken (this is becoming highly complicated).

First of all I would like to say, that I appreciate the positive =
response. I
have been a bit nerves before announcing my article, mainly because I =
did
not want to hurt any feelings. I know the team is working hard with a =
great
amount of passion.

Like Matt stated, many of the examples I have used, are from older =
modules.
I know that the team has come a long way since then. I have been =
sneaking
into the CVS repository from time to time, and the new code is looking =
very
impressive. Matt, I am looking forward to the demo=85

A couple of thoughts:

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

I like the idea of default messages. It will bring down the amount of
phrases needed to be translated, and it will ensure, that the same
formulation is uses in every module. I have seen many duplicated =
phrases,
translating phpWebSite version 0.1.0. This could easily be avoided =
having a
default amount of phrases for use.

In my article I forgot to mention, that I think the team should consider =
a
standard for showing error-, warning-, information and debug messages. =
Some
of the messages might be default messages, like the "empty list" =
message.
Other messages may depend entirely on the module. In each case, there =
should
be a default location for the message, i.e. implemented via a {MESSAGE}
variable.

Titles
-------------------
I think the tabbed navigation design Matt has described will solve many =
of
the problems I have mentioned in my article. The new design could be =
styled
in numerous ways, if the html is carefully prepared. My first thought =
was to
replace the Content and Administration titles by icons, aligning them
vertically to the left. I think Red Hat or Mandrake has a control panel
looking something like that.

Input
-------------------
> I think that some sample forms should be put together to illustrate
> some real life examples.

I think this is a great idea. If someone could produce a couple of =
realistic
input forms and publish them, we (the phpWebSite community) could try to
come up with some examples for the interface. I am not a designer, but I
will give it a try.
This brings me to another subject. Right now this thread is the center =
for
our discussion. Months ago it was in another thread. I have an article =
on my
site related to our discussion, and rck has another article on his site,
with advices on "what to do" and "what not to do" in concern of styling
phpWebSite.
It is becoming rather fragmented, and I think we need a single place, =
where
we can continue the discussion, collect the ideas, with bits and pieces =
of
code, screenshots and examples. I think it is very important, that we =
split
up our discussion in categories (titles, input, lists etc.), not =
necessarily
in those categories I have used in my article.

Another thing about input forms. It would be nice, if the cursor was
automatically placed in the first input field, as long as it is not a
dropdown (I hate dropdowns because they interferes with page scrolling =
and
my mouse wheel). Anyway, this is just a "nice to have" thing. It could
easily be accomplished with a standard JavaScript function, called =
onload.

- Michael Rasmussen (TechElephant)

Re: SV: [Phpwebsite-developers] Defining and implementing designstandards in phpWebSite

[Matthew M. <ma...@tu...>]

> It is becoming rather fragmented, and I think we need a single place, where
> we can continue the discussion, collect the ideas, with bits and pieces of
> code, screenshots and examples. I think it is very important, that we split
> up our discussion in categories (titles, input, lists etc.), not necessarily
> in those categories I have used in my article.

We may want to consider forming a wiki site for 1.x standards. Then we
could play around with some ideas. Mike might set it up for us if
someone is willing to administrate.

-- 
Matthew McNaney
Internet Systems Architect
Electronic Student Services
Appalachian State University
Phone: 828-262-6493
http://phpwebsite.appstate.edu
http://ess.appstate.edu

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

[Matthew M. <ma...@tu...>]

> Whilst we're on the subject of Layout, is there anything on the radar 
> for allowing more than one theme.tpl (or whatever the basic structure 
> file is) where an admin gets to pick a different one depending on a 
> module/pagemaster page/category.

I am going to say yes because I know it has been requested. I will leave
it up to you to remind me of it though :)

-- 
Matthew McNaney
Internet Systems Architect
Electronic Student Services
Appalachian State University
Phone: 828-262-6493
http://phpwebsite.appstate.edu
http://ess.appstate.edu

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

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

Perhaps someone should write some documentation and define the base 
classes as I don't see the similarity between Xaraya and our 4 tier 
approach at all.

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

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

[Mike N. <mh...@us...>]

On Wed, 2005-01-05 at 15:44, Shaun Murray wrote:
> Perhaps someone should write some documentation and define the base 
> classes as I don't see the similarity between Xaraya and our 4 tier 
> approach at all.

Shaun,
I'm working on an update to my debug theme, and Wendall is working on
installation of a wiki at phpwebsite-comm.

-- 
Mike Noyes <mhnoyes at users.sourceforge.net>
http://sourceforge.net/users/mhnoyes/
SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs