[Building Sakai] priority UI changes

[Sean Keesler]

I agree.

It is a very rare case that a piece of work done for one class is
"reusable" for another. In fact, I can imagine some instructors being
rather disappointed when they learn that their assignments are SO
similar to another class' assignment that the student didn't have to
do ANYTHING NEW. No new learning may mean bad curriculum/program
design! It seems like selecting something from resources would be at
best an edge case under an "advanced" group of choices.

Not to say that students wouldn't build on past work to create
derivative works, but that speaks to content authoring, versioning and
features that are not at all part of Sakai 2. If students are creating
derivative works, it is going to happen outside of Sakai.



Sean Keesler
130 Academy Street
Manlius, New York 13104 USA
315-663-7756
sean.keesler at threecanoes.com



On Fri, Oct 23, 2009 at 10:08 AM, Charles Hedrick <hedrick at rutgers.edu> wrote:
> Incidentally you'll see a common theme: Sakai has a tendency to use
> one level too much of dialog when dealing with attachments-like
> thiings, whether files or portfolio forms. What you'd like to see is
> on the main test or assignment or wizard a list of the current
> attachments, with an upload button that uploads new ones. The result
> would show as one more thing on the list. In contrast, Sakai tends to
> have a button "add attachment" that brings up another screen. In the
> best case that screen has a view of your resources and a button saying
> "upload." After some head-scratching most users can probably find the
> upload button, although they wonder why we made them click upload
> twice. The problem is that once having done the upload, it isn't clear
> to them that they're now one level down in menus, and need to get back
> to the main one. The worst case is where the extra screen doesn't have
> an upload button. It just shows you Resources, and you have to know to
> click "Add" in a folder, upload there, and select the uploaded item.
> By that time the user forgets what they were trying to do in the first
> place.
>
> This is caused by a common problem: Developers think users are going
> to want to attach existing objects: files from resources or forms
> already filled out. I very much doubt that most of our users even
> realize they have a worksite. You don't want to add another level to
> all the UIs to allow use of existing files. My suggestion is to use a
> widget like the "Action" pulldown in Resources, You'd have a button
> "attach" that pulled down to "Upload file" and "Use existing file from
> Worksite." I'd like to see a common approach throughout Sakai, since
> this issue occurs all over the place. I've flagged the ones that I
> think are worst.
>
>
>
> On Oct 23, 2009, at 9:45 AM, Charles Hedrick wrote:
>
>> I realize it's late for 2.7, but there are a few areas causing us so
>> much trouble with users that I'd like to find a way to prioritize
>> them. I'm sure others might have different priorities, but mine are
>>
>> http://jira.sakaiproject.org/browse/SAK-17273  - assignment tool
>> losing assignments; because of the way uploads are done, there's an
>> extra level of interaction that confuses users. They think they've
>> finished when they haven't. The result is faculty telling us that a
>> student reports they've submitted an assignment but Sakai has lost
>> it. We ended up building a screen that finds all attachments
>> submitted for an assignment, even if the assignment wasn't
>> submitted. This allows faculty to find the missing assignments.
>> However they would clearly prefer not to have them missing in the
>> first place.
>>
>> http://jira.sakaiproject.org/browse/SAK-17270 - tests and quizes
>> losing submissions. This one just became clear to me yesterday,
>> after processing the Nth report from a student claiming he had
>> submitted an assessment when he hadn't. The final confirmation
>> screen is probably the wrong design. We actually asked for this.
>> Students had been doing "submit for grading" without intending it.
>> As a local patch we added a Javascript confirmation box "are you
>> sure". Stanford agreed, but turned it into a normal screen. The
>> problem is that if students don't read the screen carefully (and
>> many don't) they think the extra screen is the final submit
>> confirmation. So we have otherwise good students telling faculty
>> that the submitted something they didn't, and faculty believing that
>> Sakai is losing submissions. We have a workaround for this as well:
>> we have a way to recover all the data for assessments that weren't
>> submitted. I think the best approach is to go back to the Javascript
>> confirmation box. Students are used to confirmation boxes, and are
>> unlikely to confuse an "are you sure" popup with having finished.
>>
>> http://jira.sakaiproject.org/browse/SAK-17271 and http://jira.sakaiproject.org/browse/SAK-17270
>> .  Together these deal with the continuing complaints we get that
>> OSP is too complex to use. In 2.6 work was done on the generation of
>> portfolios to help that end. We need similar work on the data entry
>> side.
>>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>