Does our Pager actually make sense? ( was Re: Problems again withRSF templates for paging controls and more )
Allison Bloodworth
abloodworth at berkeley.edu
Wed Dec 19 03:38:40 UTC 2007
Aaron and I had a good chat about this today. I'm betting that during
the Fluid Content Management Research (http://wiki.fluidproject.org/
display/fluid/Content+Management+Research) project running over the
next couple of months where we look at how users manage their content
in Sakai we will get some good information on this area (e.g. paging
in the context of how users view and interact with content that lives
in Sakai). This concept of different types of 'paging' is actually
probably a good item to add to our focus structure document (a list
of some things we might want to watch for during our research).
I recommended to Aaron that if possible, Steve should hold off on
further development of the RSF pager until we have at least initial
findings from this research to inform some designs (probably of
different types of pagers for different contexts, such as search
results vs. operating on objects like student records). It is also
quite possible that this will become a Fluid component, so if it can
wait then perhaps Steve could leverage that code as well. Does this
sound feasible, Steve?
I will also add these different types of paging to the list of design
patterns that either the Sakai design patterns group or the larger
Fluid design pattern group could think about. There is already an
"Item Pagination" design pattern in the Sakai Library (http://
bugs.sakaiproject.org/confluence/display/DESPAT/Item+Pagination), and
it may be that we just need to think of some sub-patterns (e.g. just
like there are 'List Ordering' & 'Layout Preview' sub-patterns for
'Drag-and-Drop' in the Fluid design pattern library) to further
describe how 'paging' might be implemented differently in different
contexts. I'm also checking with folks at Kuali Financial for ideas,
as I believe they are also often doing operations on a selection of
records.
Cheers,
Allison
On Dec 17, 2007, at 2:25 PM, Daphne Ogle wrote:
> I guess that depends on how quickly we can find someone to work on
> it :)
>
> Steve was looking for a wiki space to work some of this out in so
> that's what this is about. Based on his response I thought he
> wanted to start drawing some options -- is that right Steve?
> Personally I just don't have any cycles right now -- which is why I
> sent the previous message: "Anyone have the time and inclination
> to draw up some paging options? Sounds like Steve is willing to
> put some development time into this."
>
> -Daphne
>
>
> On Dec 17, 2007, at 1:41 PM, Aaron Zeckoski wrote:
>
>> This is a good start but how long would you guess it will be
>> before we
>> see wireframes/html/javascript for this?
>> Just want to get a sense of whether we should hold off or put work
>> into building a component to use the old method.
>> -AZ
>>
>>
>> On Dec 17, 2007 3:50 PM, Daphne Ogle <daphne at media.berkeley.edu>
>> wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>> Daphne Ogle wrote:
>>> Anyone have the time and inclination to draw up some paging
>>> options? Sounds
>>> like Steve is willing to put some development time into this.
>>>
>>>
>>> I would love to do this. Is there an existing wiki page
>>> somewhere where I
>>> should dump this information?
>>>
>>> -Steve
>>>
>>> Hey Steve,
>>>
>>> Sorry for not responding earlier. Somehow I missed your response.
>>>
>>> I've created a page in the Fluid wiki (we already had it listed
>>> as a future
>>> component just needed some fleshing out),
>>> http://wiki.fluidproject.org/x/hRQa. I tried to capture some of
>>> this email
>>> conversation plus various other conversations about the same
>>> issue. I also
>>> added links to existing design patterns and some of the
>>> applications being
>>> discussed as benchmarks.
>>>
>>> -Daphne
>>>
>>>
>>>
>>>
>>>
>>> -Daphne
>>>
>>> On Dec 11, 2007, at 5:33 AM, John Norman wrote:
>>>
>>>
>>> I don't think usability _requires_ the paging control to be at
>>> the bottom of
>>> the page. My personal webmail page has it at the top and bottom
>>> in quite a
>>> usable way using the technique Steve is suggesting. [image attached]
>>> [see attachment: "tabbing.tiff", size: 124082 bytes]
>>>
>>>
>>>
>>> Notice they put a drop down in the middle to give the number of
>>> results on
>>> the page
>>>
>>> John
>>>
>>> On 11 Dec 2007, at 09:53, swg wrote:
>>>
>>>
>>> Sean Keesler wrote:
>>> While doing a recent UX walkthrough of the OSP matrix tool I
>>> annotated that
>>> the pager takes up significant screen real estate at the top of
>>> the screen,
>>> forcing the data below below the fold. Reading this post reminded
>>> me that
>>> this is not just an OSP UI enhancement, but that it was a
>>> complaint about
>>> all of the paged lists I have seen in Sakai. Does the RSF pager
>>> look the
>>> same as the other pagers I have seen?
>>>
>>>
>>> That was my original intention yes, to make it have the 4 buttons
>>> and the
>>> drop down thing, etc. like the original sakai pages. But after
>>> spending a
>>> good portion of a day (this was a few months ago) trying to find
>>> a website
>>> that didn't page by just using 5 or 6 hyperlinks composed of a
>>> few arrows
>>> and numbers, I started to wonder if it really made sense.
>>> There's also the chance that I'm just being extremely lazy, and
>>> it's easier
>>> for me to render a couple hyperlinks than to either wrap buttons
>>> in a GET
>>> form and/or write a bunch of javascript.
>>>
>>> -Steve
>>>
>>> ( I still haven't seen another pager on the internet that looks
>>> like ours.
>>> There's a good chance I'm not looking hard enough ).
>>>
>>>
>>> If the pager is going to be at the top of tables of data, I
>>> wondered if it
>>> should even be displayed if there is only one page (<= 10) of
>>> results. For
>>> example, the matrix tool is highly unlikely to have 10 matrices
>>> deployed in
>>> a worksite. In that case you still have data forced down several
>>> rows even
>>> though the pager is useless.
>>>
>>> I suppose that if it is at the bottom, the same argument
>>> (uselessness) could
>>> be made, although it wouldn't have the same impact on the UI.
>>>
>>>
>>> ------------------------------
>>> Sean Keesler
>>> The Living SchoolBook
>>> 030 Huntington Hall
>>> Syracuse University
>>> 315-443-4768
>>>
>>>
>>>
>>>
>>> On 12/11/07 3:41 AM, "Ian Boston" <ieb at tfd.co.uk> wrote:
>>>
>>>
>>>
>>> Pagers should use GET s and not javascript, they are views.
>>>
>>> APIs must support paging and sorting, if sorting is required.
>>>
>>> yahoo design patterns on pagers are worth a read.
>>>
>>> Ian
>>> Sent from my Pearl, sorry about the briefness and spelling!
>>>
>>> -----Original Message-----
>>> From: swg <sgithens at caret.cam.ac.uk>
>>>
>>> Date: Tue, 11 Dec 2007 01:17:02
>>> To:Sakai UI UI <sakai-dg-ui at collab.sakaiproject.org>
>>> Cc:sakai-dev at collab.sakaiproject.org
>>> Subject: Does our Pager actually make sense? ( was Re: Problems
>>> again with
>>> RSF templates for paging controls and more )
>>>
>>>
>>> Hello UI (and CC'd source part) Developers,
>>>
>>> I've had some ongoing quandary's about our pager, and they have
>>> resurfaced as I've been reminded that I never quite finished
>>> debugging
>>> the javascript and config options for the rsf version of the
>>> Sakai Pager.
>>>
>>> Mostly, I'm wondering if the sakai pager really makes sense? I
>>> realize
>>> that we're supposed to keep using it so the Sakai user interface is
>>> 'consistent', but I'm hard pressed to find another pager on any
>>> other
>>> web page that looks like ours. Maybe I'm just being overcritical.
>>>
>>> Like, most web sites have some links in plain text with some
>>> arrows and
>>> a couple numbers:
>>>
>>> 1 _2_ 3 >
>>>
>>> or maybe something more complicated,
>>>
>>> << < 1 _2_ 3 ... > >>
>>>
>>> Ours has a bunch of buttons. And no way to just skip forward a
>>> couple
>>> pages. I'm assuming it's like this because in the past we've almost
>>> exclusively loaded the entire table into memory and the pager had
>>> buttons because it required submission from a <form/> of some sort.
>>>
>>> I've been trying to return to a simpler more RESTful time, almost
>>> PHP'ish, where paging means submitting a GET url, and you do a
>>> fast SQL
>>> query with the LIMIT BY and SORT BY options. It's really weird
>>> doing
>>> that with our current pager widget because it forces you to use
>>> Javascript to power the buttons to do the GET request. Unless you
>>> resort to really complicated GET <forms>.
>>>
>>> Do you think we ever might give some thought to a pager that uses
>>> simple
>>> links like other websites?
>>>
>>> On a related tangent, does anyone know of a UI Design Study or
>>> whitepaper that gives super detailed behavior expectations from
>>> sorted/searched/paged tables?
>>>
>>> I've always wondered about things like:
>>>
>>> If I go to the 3rd page of a paged table and choose to sort by a
>>> different column, should I stay on the 3rd page of the newly sorted
>>> table, or should I go back to the first page? What if I'm just
>>> clicking
>>> to sort on the same column in the other direction. What if it's a
>>> weighted sort on one of the other columns? What if you enter a
>>> search
>>> term?
>>>
>>> I would guess that if you change any of the options you should
>>> probably
>>> go back to the first page.
>>>
>>> Thanks,
>>> Steve
>>>
>>>
>>>
>>> ----------------------
>>> This automatic notification message was sent by Sakai Collab
>>> (https://collab.sakaiproject.org/portal) from the DG: Development
>>> (a.k.a.
>>> sakai-dev) site.
>>> You can modify how you receive notifications at My Workspace >
>>> Preferences.
>>>
>>> ----------------------
>>> This automatic notification message was sent by Sakai Collab
>>> (https://collab.sakaiproject.org/portal) from the DG: Development
>>> (a.k.a.
>>> sakai-dev) site.
>>> You can modify how you receive notifications at My Workspace >
>>> Preferences.
>>>
>>>
>>>
>>>
>>> ----------------------
>>> This automatic notification message was sent by Sakai Collab
>>> (https://collab.sakaiproject.org/portal) from the DG: User
>>> Interaction site.
>>> You can modify how you receive notifications at My Workspace >
>>> Preferences.
>>>
>>>
>>>
>>>
>>>
>>> ----------------------
>>> This automatic notification message was sent by Sakai Collab
>>> (https://collab.sakaiproject.org/portal) from the DG: User
>>> Interaction site.
>>> You can modify how you receive notifications at My Workspace >
>>> Preferences.
>>>
>>>
>>>
>>>
>>> Attachments:
>>>
>>> tabbing.tiff
>>> https://collab.sakaiproject.org/access/content/attachment/
>>> e51807d5-edf5-4ee1-8008-cefdfb874a74/tabbing.tiff
>>>
>>> ----------------------
>>> This automatic notification message was sent by Sakai Collab
>>> (https://collab.sakaiproject.org/portal) from the DG: Development
>>> (a.k.a.
>>> sakai-dev) site.
>>> You can modify how you receive notifications at My Workspace >
>>> Preferences.
>>>
>>>
>>>
>>> Daphne Ogle
>>> Senior Interaction Designer
>>> University of California, Berkeley
>>> Educational Technology Services
>>> daphne at media.berkeley.edu
>>> cell (510)847-0308
>>>
>>>
>>>
>>> [see attachment: "message0.html", size: 28213 bytes]
>>>
>>>
>>> Attachments:
>>>
>>> message0.html
>>> https://collab.sakaiproject.org/access/content/attachment/
>>> 977112fe-d7ee-4b51-000e-cac48bfd2f3a/message0.html
>>>
>>> ----------------------
>>> This automatic notification message was sent by Sakai Collab
>>> (https://collab.sakaiproject.org/portal) from the DG: User
>>> Interaction site.
>>> You can modify how you receive notifications at My Workspace >
>>> Preferences.
>>>
>>>
>>>
>>>
>>> ----------------------
>>> This automatic notification message was sent by Sakai Collab
>>> (https://collab.sakaiproject.org/portal) from the DG: Development
>>> (a.k.a.
>>> sakai-dev) site.
>>> You can modify how you receive notifications at My Workspace >
>>> Preferences.
>>>
>>>
>>>
>>> ------------------------------------------------------
>>> Michelle D'Souza
>>> Software Developer, Fluid Project
>>> Adaptive Technology Resource Centre
>>> University of Toronto
>>>
>>>
>>>
>>>
>>>
>>> Daphne Ogle
>>> Senior Interaction Designer
>>> University of California, Berkeley
>>> Educational Technology Services
>>> daphne at media.berkeley.edu
>>> cell (510)847-0308
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> fluid-work mailing list
>>> fluid-work at fluidproject.org
>>> http://fluidproject.org/mailman/listinfo/fluid-work
>>>
>>>
>>
>>
>>
>> --
>> Aaron Zeckoski (aaronz at vt.edu)
>> Senior Research Engineer - CARET - Cambridge University
>> [http://bugs.sakaiproject.org/confluence/display/~aaronz/]
>> Sakai Fellow - [http://aaronz-sakai.blogspot.com/]
>
> Daphne Ogle
> Senior Interaction Designer
> University of California, Berkeley
> Educational Technology Services
> daphne at media.berkeley.edu
> cell (510)847-0308
>
>
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work
Allison Bloodworth
Senior User Interaction Designer
Educational Technology Services
University of California, Berkeley
(415) 377-8243
abloodworth at berkeley.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20071218/32bd2647/attachment.html>
More information about the fluid-work
mailing list