source: products/qPloneTiles/tags/0.2/README.txt @ 1

Last change on this file since 1 was 1, checked in by myroslav, 18 years ago

Building directory structure

  • Property svn:eol-style set to native
File size: 2.4 KB
Line 
1qPloneTiles
2
3
4Inspiration
5
6  "#120: Support and use "Tile" links":
7 
8  One of the classic, testable usability laws is Fitt's
9  Law, which simply says that the efficiency of a user
10  interface item is directly proportional to its size.
11  Plone currently has a lot of user interface items that
12  could have bigger clickable areas without changing the
13  elements themselves.
14                     
15  Proposed by::
16    Alexander Limi
17  Proposal type::
18    User interface
19  Assigned to release::
20    Plone 3.0
21  State::
22    being-discussed
23
24Motivation
25
26  A lot of the user interface elements in Plone only
27  work when you click the links they define instead
28  of the entire UI element. This is bad UI, although
29  most web-based systems work this way.
30
31  I have already experimented with changing this for
32  a limited set of items in previous Plone versions;
33  in Plone 2.0 I made the entire item in the
34  navigation tree clickable and it indicates when it
35  is selected with a block of color around itself,
36  so you know you can click (this doesn't work in
37  Internet Explorer because it's a buggy piece of
38  crap, more about that later ;). In Plone 2.1 I made
39  all the portlet items be clickable in the entire
40  area through a display:block definition of the link
41  tag.
42  It's time to take this to the next level.
43
44
45Proposal
46                                         
47  Because of the limitations (as far as I have found,
48  at least), it's hard to make certain elements
49  entirely clickable through re-defining the link tag
50  only. In a separate project I was involved in, we
51  used a tiny piece of JS to assign clickable behaviour
52  to an arbitrary element, which worked well.
53  (Note that the normal "read more" or whatever link
54  still remains, so it's not removing links for people
55  that have JS turned off or browsing via lynx or
56  similar — this is merely augmenting the link behaviour,
57  not moving it into JS.)
58  This also has the advantage of being able to make any
59  area clickable. My pet peeve is that Plone in "Summary
60  view" doesn't accept clicks anywhere within the area
61  of one of the items listed, but only on the links. The
62  interface would be so much more efficient if we could
63  click anywhere within that item's area.
64 
65                                         
66Implementation
67                                         
68  We should find a good way to define an area as clickable.
69  In the project I was in, we defined that on the tag
70  itself, and did it explicitly, but this can possibly be
71  improved.
Note: See TracBrowser for help on using the repository browser.