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

Wed Jan 9 00:43:17 UTC 2008

Hi Peter,

I'm sorry for the delayed response to your question. I wanted to talk  
with Steve first to make sure I was understanding his request and  
constraints, and we were finally able to connect yesterday. He is  
finishing an RSF version of the pager which can be configured to look  
like either the current Sakai pager or a pager similar to the one in  
the Yahoo! design pattern for item pagination (http:// 
developer.yahoo.com/ypatterns/pattern.php?pattern=itempagination).  
Steve does need to complete this quickly, as there is someone in need  
of it now.

I also talked with Colin about this and the Pager is not in the  
current list of planned Fluid components. For the next release, 0.3,  
which is expected to come out in March (see http:// 
wiki.fluidproject.org/display/fluid/Fluid+Project+UX+Plan), Fluid  
will be working on File Uploader and uPortal portlet layout manager  
components. Then for the next two releases (0.4 & 0.6), we currently  
have two components each selected for development. Depending on  
priorities the Pager may end up being a component created for a  
future release, but we don't have those plans in place at this point.

However, I was still hoping to be able to contribute some personal  
design time to the Pager and thought I would be much more informed  
after our user research was completed. I definitely didn't want to  
hold Steve up, however, if Steve needed to complete the work quickly,  
or someone else was able to work on designs now. I've let Steve know  
I'm available as a (limited) design resource for what he's working on  
now and would be happy to continue to provide advice in the future if  
he needs it. Additionally, if any exciting new ideas arise from the  
user research (which should be complete in about 2 months) in this  
area, we will definitely let him know.

Cheers,
Allison

On Dec 19, 2007, at 2:37 PM, Knoop, Peter wrote:

> Allison, how long do anticipate before you have your initial findings,
> or in other words, how long are you asking Steve to wait?
>
> Thanks.
>
> -epter
>
>> -----Original Message-----
>> From: Allison Bloodworth [mailto:abloodworth at berkeley.edu]
>> Sent: Tuesday, December 18, 2007 10:39 PM
>> To: fluid-work at fluidproject.org; sakai-dev; Sakai UI UI
>> Cc: Aaron Zeckoski; Daphne Ogle
>> Subject: Re: Does our Pager actually make sense? ( was Re: Problems
>> again withRSF templates for paging controls and more )
>>
>> 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
>>
>>
>>
>>
>> [see attachment: "message0.html", size: 47943 bytes]
>>
>>
>> Attachments:
>>
>> message0.html
>> https://collab.sakaiproject.org/access/content/attachment/1e3de5d1-
>> aee2-4f3d-005b-80f699ae5ba6/message0.html
>>
>> ----------------------
>> 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.
>

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: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20080108/17edf2e0/attachment.htm>