[Building Sakai] Roster2 changes

Fri Nov 28 10:39:03 PST 2014

Hi Neal,

Thanks for getting back so quick. My replies are inline.

Cheers,
Adrian.

On 28 November 2014 at 18:26, Neal Caidin <neal.caidin at apereo.org> wrote:

> Hi Adrian,
>
> The things that I notice are:
>
> 1) Why is there are groups pop-down menu with every person's entry?
> Picking a group seems to update the "Groups:" menu to filter the whole list
> based. Putting this option at the individual person level when it is a view
> level doesn't make sense to me.
>

The idea behind that what if you were 3000 entries down and you wanted to
look at the other members of a group, you could just select it there and
then. Maybe it's overkill and I'd be happy to get rid.

>
> 2) Official Photos vs Pictures from Profile.  I'm curious if it would make
> more sense for this to be an administrative property and not a User
> interface element? I don't know that administrators would want to put this
> power in the hands of instructors, simply because it might cause them
> confusion, not because it would do them any harm.
>

It's just how the current Roster works. It may well be that it is unused
and should be a admin prop. I'm open to more opinions on that as I'm
agnostic.

>
> 3) Sorting. Maybe sorting doesn't make sense in a infinite scroll model?
> But we do currently have sorting based on name, user id , and role and I
> imagine people would like to keep that option.
>

I got rid of sorting as I think the only thing you use that for is to find
a particular user. I'm hoping the search will do that job. We can put that
sorting back in, but it means more caching and more memory usage on the
server side, that's all. I don't think people will use it once they start
using the search, though.

>
> 4) I kind of like that the "photo" or image, but on the flip side, it
> takes up a lot of extra real estate, as does the multiple fields aligned
> vertically (Name, User Id, Role, Groups).  For an infinite scroll this
> means it would take someone a lot longer to scroll through. On the other
> hand, seeing someone's picture is a powerful way to identify someone when
> you cannot remember his/her name. I just have a feeling that there is a
> better option for the display and UI behavior, but I don't know what it is.
> Perhaps instead of Official vs Profile picture it should be an option to
> show photos vs not? And if no photo is shown then display fields in regular
> table format to squeeze more data per page?  Not sure.
>

Juanjo's already raised a ticket about putting them in a grid when the
screen is wide enough, and then columning them when the screen shrinks. CSS
media queries will do that, I should think. I think we should always show
the photo, personally, as it keeps that ui consistent.

>
> Would you be interested in getting feedback from the Teaching and Learning
> group and see what they say?
>

Let me address the stuff you raise here first, then we can think of going
to the group with it. I'm not sure if I have the time to dedicate to some
serious work coming out of the group, so I'd rather lay off that option for
the moment.

> Thanks!!!
> Neal
>
>
>
>
>   Adrian Fish <adrian.r.fish at gmail.com>
>  November 28, 2014 at 1:03 PM
> Hi Neal,
>
> What bits are confusing? Lay 'em on me :)
>
> Adrian.
>
>
>   Neal Caidin <neal.caidin at apereo.org>
>  November 28, 2014 at 8:52 AM
> Please do not merge these changes into 10.x.
>
> Being a new feature this needs time to shake the interface out a bit in
> trunk, imho. While it looks really really cool, there are a couple of
> interface elements that seem confusing to me.
>
> We are trying to get 10.3 out the door and I worry that this would add
> significant risk. Plus, it should be subject to the Maintenance Branch
> Merge Policy [1].
>
> [1]
> https://confluence.sakaiproject.org/display/TCC/Maintenance+Branch+Merge+Policy
>
> Thanks!
> Neal
>
>
>
>   Adrian Fish <adrian.r.fish at gmail.com>
>  November 27, 2014 at 11:49 AM
> I've just fixed the permissions one. I think you've put the tickets
> against the wrong project, though. Roster 2's now a component in the Sakai
> project, so we've got tickets split between. It got me as well. Just leave
> them where they are this time, unless we really need to move them in the
> Sakai project.
>
> If anybody on the list wants to create a Roster2 ticket, they should be in
> the Sakai project, under the Roster2 component , like this one
> https://jira.sakaiproject.org/browse/SAK-27501. Is that right, Sam?
>
> Cheers,
> Adrian.
>
>
> _______________________________________________
> 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"
>   JUAN JOSé MEROñO SáNCHEZ <jjmerono at um.es>
>  November 27, 2014 at 8:39 AM
>  Hi Adrian,
>
>     I've been testing roster2 now in trunk and it is great !!
>     Thank you for all the suggestions you've added to the branch before
> merging into trunk...
>
>     I've created a set of jiras so that we don't forget other suggestions
> that could improve this new UI.
>
>
> https://jira.sakaiproject.org/issues/?jql=key%20in%20(RSTR-73%2CRSTR-74%2CRSTR-75%2CRSTR-76%2CRSTR-77)
> <https://jira.sakaiproject.org/issues/?jql=key%20in%20%28RSTR-73%2CRSTR-74%2CRSTR-75%2CRSTR-76%2CRSTR-77%29>
>
>     But there is one thing that we solved in 10.x that is broken now in
> trunk:
>
>         https://jira.sakaiproject.org/browse/SAK-27501
>
>     I don't know if it will be too disruptive to merge this new UI into
> 10.x, any concerns/opinions?
>
> Thanks !!
>
> El 21/11/2014 22:53, Sam Ottenhoff escribió:
>
> _______________________________________________
> 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"
>   Sam Ottenhoff <ottenhoff at longsight.com>
>  November 21, 2014 at 4:53 PM
> Great job Adrian.  The infinite scroll worked really well for me and was
> fast in a huge testing site.
>
> My only major confusion was the new Groups dropdown when viewing users. I
> was unclear if I was assigning the user to a group or limiting my view to
> that one group only.
>
> I would drop the pain of the separate branch and move your code into trunk
> quickly!
>
>
> _______________________________________________
> 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"
>
>
> --
> Neal Caidin
> Sakai Community Coordinator
> Apereo Foundation
> neal.caidin at apereo.org
> Skype me! (but let me know in advance for the first interaction) - nealkdin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20141128/44a21e10/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1168 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20141128/44a21e10/attachment.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20141128/44a21e10/attachment-0001.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1098 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20141128/44a21e10/attachment-0002.jpg 