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

Aaron Zeckoski aaronz at vt.edu
Mon Dec 17 21:41:30 UTC 2007


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/]



More information about the fluid-work mailing list