Hi koha-devel, I've started to work on Koha HEAD templates and my first remark is about links. Why links are replaced by form buttons? This construction is complicated and against semantic. For example, in members/moremember, reaching members/readingrec (reading records) requires to use a form button. There are several reason not to do this: - semantically incorrect, a form is supposed to have textfields, select boxes, a reset button and a submit button. - when my mouse cursor is over the button I don't see in the status bar where clicking will bring me - most of form are with method post and have a variable (like a borrower number) so I have a warning a each reload of the new page. Furthermore, I don't see the borrowernumber in the URL. - painful to write in template HTML code In my opinion, for action links, we could have icons. For example in members/moremember, instead of a vertical list of possible action on the borrower, we could have a text-align:center horizontal list (display:inline) of pretty icons (there are plenty beautiful icons available for free applications like Koha). A tool tip for each icon giving details on each action. I don't know/understand the reasons why buttons where choosen instead of normal links to do links job, but I would be happy to have information :-) (found nothing in IRC logs and koha-devel archives). Bye -- Pierrick LE GALL INEO media system
On Fri, Mar 31, 2006 at 03:50:24PM +0200, Pierrick LE GALL wrote:
I've started to work on Koha HEAD templates and my first remark is about links. Why links are replaced by form buttons? This construction is complicated and against semantic. Are you working with PROG templates?
In my opinion, for action links, we could have icons. For example in members/moremember, instead of a vertical list of possible action on the borrower, we could have a text-align:center horizontal list (display:inline) of pretty icons (there are plenty beautiful icons available for free applications like Koha). A tool tip for each icon giving details on each action.
I don't know/understand the reasons why buttons where choosen instead of normal links to do links job, but I would be happy to have information :-) (found nothing in IRC logs and koha-devel archives). The only problem with icons is that they often include text which must be translated. If you can find icons that won't include text to include I'm all for it.
Cheers, -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
On Fri, 31 Mar 2006 06:04:40 -0800 Joshua Ferraro <jmf@liblime.com> wrote:
On Fri, Mar 31, 2006 at 03:50:24PM +0200, Pierrick LE GALL wrote:
I've started to work on Koha HEAD templates and my first remark is about links. Why links are replaced by form buttons? This construction is complicated and against semantic.
Are you working with PROG templates?
Of course I am. We said only PROG was correct on HEAD.
In my opinion, for action links, we could have icons. [...]
The only problem with icons is that they often include text which must be translated. If you can find icons that won't include text to include I'm all for it.
Icons without text? That's what we work with everyday (or do I miss something?). See some beautiful samples in Tango project gallery page [1] or in Jakub Steiner presentation page [2]. In the following sample screenshot [3], I use icons from Jakub Steiner. [1] http://tango-project.org/Tango_Icon_Gallery [2] http://jimmac.musichall.cz/i.php [3] http://le-gall.net/pierrick/images/pwg_admin_sample.png Cheers, -- Pierrick LE GALL INEO media system
Pierrick LE GALL wrote:
On Fri, 31 Mar 2006 06:04:40 -0800 Joshua Ferraro <jmf@liblime.com> wrote:
In my opinion, for action links, we could have icons. [...] The only problem with icons is that they often include text which must be translated. If you can find icons that won't include text to include I'm all for it.
Icons without text? That's what we work with everyday (or do I miss something?). See some beautiful samples in Tango project gallery page [1] or in Jakub Steiner presentation page [2].
I think we should really avoid using images in the Koha templates as much as possible. While icons may be individually small in size, they will make a difference to page loading times for libraries with slow internet connection speeds e.g., rural libraries connected via dial-up modems. They could choose to not display images to speed up the page loading times but then you will need a meaningful "alt" text for each icon in the language the library uses. So they will need text, as Joshua says. Cheers, Richard -- Richard Anderson Project Manager Katipo Communications PO Box 12487 Wellington Web: http://www.katipo.co.nz/ Ph: (04) 934 4251 (DDI) (04) 934 1285 Fax: (04) 934 1286 Mobile: 021 043 3649
Pierrick LE GALL <pierrick@koha-fr.org>
I've started to work on Koha HEAD templates and my first remark is about links. Why links are replaced by form buttons? This construction is complicated and against semantic.
I agree. Owen Leonard <oleonard@athenscounty.lib.oh.us> wrote:
Using javascript by itself isn't a safe way to prevent unwanted destructive consequences: http://radar.oreilly.com/archives/2005/05/google_web_acce_1.html
The only way to combine a link with a delete action safely would be to make an intermediary page with a confirm button.
Thanks for sharing that link about Google. I'll add it to my page of Google Bugs at http://mjr.towers.org.uk/blog/2006/google Arguably, irreversible actions should have a confirmation page to avoid the problem of wild-clicking and then hitting the wrong dialogue box button key. So, ultimately, it would meet your recommendation to use a POST for the destructive part. (Arguably, destruction should be an HTTP DELETE but damned if I know how to make today's browser send that.) Richard Anderson <richard@katipo.co.nz>
Joshua Ferraro <jmf@liblime.com> wrote:
In my opinion, for action links, we could have icons. [...] The only problem with icons is that they often include text which must be translated. If you can find icons that won't include text to include I'm all for it.
Icons without text? That's what we work with everyday (or do I miss something?). See some beautiful samples in Tango project gallery page [1] or in Jakub Steiner presentation page [2].
I think we should really avoid using images in the Koha templates as much as possible. While icons may be individually small in size, they will make a difference to page loading times for libraries with slow internet connection speeds e.g., rural libraries connected via dial-up modems.
If the icons were both image and text on a standard base button background image(s), it could: 1. make templates easy to translate because there is nothing to translate in the images; 2. make templates easier to re-skin, simply by replacing the background image and stylesheet, without messing up the translations; 3. maximise the space users can click on, which is good for Fitts's Law: The time to acquire a target is a function of the distance to and size of the target. Hope that helps, -- MJ Ray - personal email, see http://mjr.towers.org.uk/email.html Work: http://www.ttllp.co.uk/ irc.oftc.net/slef Jabber/SIP ask
Hi koha-devel, Sorry for the long wait before response... Owen Leonard <oleonard@athenscounty.lib.oh.us> wrote:
Using javascript by itself isn't a safe way to prevent unwanted destructive consequences: http://radar.oreilly.com/archives/2005/05/google_web_acce_1.html
The only way to combine a link with a delete action safely would be to make an intermediary page with a confirm button.
I think I missed this mail (I took it in the mailing-list archive). I know understand better why we should not have a direct link "delete this item" without intermediary confirmation page. Bye -- Pierrick LE GALL INEO media system
I've started to work on Koha HEAD templates and my first remark is about links. Why links are replaced by form buttons? This construction is complicated and against semantic.
It's /mostly/ cosmetic. There are situations (like moremember.pl) where there are a variety of actions which require both links and form buttons. Edit and Change Password, for instance, could easily be links. But Delete must be a button because it's harmful to have a destructive outcome be the consequence of a GET action. In that case, I made the decision to make all the controls buttons for the sake of consistency. I was uncomfortable at the time with the idea of styling links to resemble buttons because I was concerned about possible accessibility issues... I'm not sure my concerns were well-founded. I'm opposed to the idea of using graphical icons alone, because I feel the intranet interface needs to be as lightweight as possible. If we're talking only about the prog templates, then I think we need to focus on bare structure and not worry about making it pretty. I think graphical icons could be used in an alternative template for libraries to choose, but I don't think they're necessary for prog. -- Owen
On Fri, 31 Mar 2006 09:23:40 -0500 Owen Leonard <oleonard@athenscounty.lib.oh.us> wrote:
[...] But Delete must be a button because it's harmful to have a destructive outcome be the consequence of a GET action.
Why? you can have a confirmation box on link as well as on a button.
In that case, I made the decision to make all the controls buttons for the sake of consistency. I was uncomfortable at the time with the idea of styling links to resemble buttons because I was concerned about possible accessibility issues... I'm not sure my concerns were well-founded.
So, what's the official guideline? Paul told me to discuss it with you, so I believe what you say concerning template is the official voice :-)
I'm opposed to the idea of using graphical icons alone, because I feel the intranet interface needs to be as lightweight as possible. If we're talking only about the prog templates, then I think we need to focus on bare structure and not worry about making it pretty. I think graphical icons could be used in an alternative template for libraries to choose, but I don't think they're necessary for prog.
OK, I understand, having a bare structure as prog template suppose we have no pretty icon. Cheers, -- Pierrick LE GALL INEO media system
On Fri, Mar 31, 2006 at 05:17:30PM +0200, Pierrick LE GALL wrote:
On Fri, 31 Mar 2006 09:23:40 -0500 Owen Leonard <oleonard@athenscounty.lib.oh.us> wrote:
[...] But Delete must be a button because it's harmful to have a destructive outcome be the consequence of a GET action.
Why? you can have a confirmation box on link as well as on a button.
Using javascript by itself isn't a safe way to prevent unwanted destructive consequences: http://radar.oreilly.com/archives/2005/05/google_web_acce_1.html The only way to combine a link with a delete action safely would be to make an intermediary page with a confirm button.
In that case, I made the decision to make all the controls buttons for the sake of consistency. I was uncomfortable at the time with the idea of styling links to resemble buttons because I was concerned about possible accessibility issues... I'm not sure my concerns were well-founded.
So, what's the official guideline? Paul told me to discuss it with you, so I believe what you say concerning template is the official voice :-)
With prog templates, I guess my "official" recommendation would be to use links wherever appropriate (where user input via form fields isn't necessary), and to use a form button for any action where the direct consequence of the action is destructive (deletion of data). How does that sound? -- Owen
So, what's the official guideline? Paul told me to discuss it with you, so I believe what you say concerning template is the official voice :-)
With prog templates, I guess my "official" recommendation would be to use links wherever appropriate (where user input via form fields isn't necessary), and to use a form button for any action where the direct consequence of the action is destructive (deletion of data).
How does that sound?
I agree with Owen. I don't think there should be any design elements in the PROG templates at all. I count icons as design elements. So I think use words as links and the appropriate form button is the way to go. -- Russel Garlick Operations Manager Katipo Communications Ph: +64 4 934 1285 Fax: +64 4 934 1286 Mob: +64 27 537 1377 Skype: russelgarlick Web http://www.katipo.co.nz
participants (6)
-
Joshua Ferraro -
MJ Ray -
Owen Leonard -
Pierrick LE GALL -
Richard Anderson -
Russel Garlick