Does our Pager actually make sense? ( was Re: Problems again withRSF templates for paging controls and more )

Mon Dec 17 22:25:37 UTC 2007

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20071217/beca57f4/attachment.html>