phpgroupware-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Phpgroupware-developers] Re: style guide


From: Alex Borges
Subject: Re: [Phpgroupware-developers] Re: style guide
Date: 23 May 2003 12:43:36 -0500

El vie, 23 de 05 de 2003 a las 12:26, Kevin Scott escribió:
> and ALL icons should have alt tags
> 
> which brings up a point I've been thinking about in regards to the 
> restructering of
> the project. I really like phpgroupware and hope to start deploying it on a 
> larger
> scale. I personally have gotten used to the little gotchas here and there
> (like not using the back button in email) and can usually recover with no 
> problem.
> I totally understand the stateless nature of web apps and resulting interface
> problems that result. But I think most new users might be put off (especially 
> if no
> training is provided). anyways I was thinking of something like a usability 
> commitee
> for phpgw, a group of people to evaluate and make suggestions in a more 
> formal way
> than currently exists. Perhaps the first thing that could be done by this 
> group is
> to set up a survey for new end users to gauge reactions to various apps. Just 
> an
> idea. Thanks for your time - Kevin Scott
> 
Im not shure that there's many ppl that could provide serius work for
this although its indoubtedly a great idea. What im shure we can do is
fill the wishlists with the normal  complaints i get. Ive 700 users for
a phpgw box, and they come up with really cool ways to piss me off about
the interface. I can pass all of that frustration along, even bring a
couple of the more technicall users online to irc and the lists. Im
shure some devels will wither commit suicide or contract a hitman to
take out the users. Hey, the only reason i dont do it its that they
actually pay me to listen!...

Im deploying next month for a university of 4000 students and i know ceb
has a similar deployment. Im shure we can gather many many quirks, do's
and don'ts for the enjoyment of all developers. Its just that this kind
of bug report (usability/ui) is generally either disregarded by
developers or widely discussed. This happens because we devels normaly
fail to be sinergic (ugh, where did i get that word) and "wear the other
guy's shoes". But this is a new era for oss, i think we all agree that
if we are to be succesful we have to deliver a better user experience
than the competition, that being M$ and other horrible semigroupware or
even groupware suites.

Another idea for the StyleGuide:

When using a browse interface like the one in the addressbook or the acl
(with the arrows on top a search box and a table listing elements),
headers should all be links to sort the table by the data in that
column.

When hitting search, the state of the sort should be preserved, when
hitting search and then changing by which column to sort, the data
should still be narrowed to search. Example:

Sometimes, in the addressbook, you order by name, then hit another
category, the sort is lost. 

Other times, you search  by the letter a, then you change category, the
state of the search is lost.

Other times, you select a category, then sort, then search, the sort
gets lost....etc.

Of course, the next and back arrows should also preserve all queries,
and, where possible, the visual elements concerning the state of the
queries should be highlited for the user. For example, if you sort by a
column, the column or the header of the column should be highlighted. If
you search, then ask for a category, the searchbox should still contain
the searched string....etc.

All in all i think its a matter of consistency. If we can fix this
widget we fix 50% of the usability troubles we have in most interfaces
(ACL, Addressbook, Admin. hooks, most apps use it as well).

Then we can think about making it cooler, with more search capabilities,
some js extensions to make it autocomplete from a given string...etc.

I dont know, im just kicking stuff arround...

> >Id like to add:
> >
> >" The Back Button on EVERY browser should ALLWAYS work "
> >
> >This should be part of the test cycle of any app. Old email (anglesmail)
> >used to crash for some particular sequence of operation->back->operation
> >(view a message, delete it from message view, takes you to the previus
> >message,click back....old message doesnt exist any more!!) ...
> 
> 
> 
> _______________________________________________
> Phpgroupware-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]