[Architecture] Multi-user login conflicts

Steve Lee steve at opendirective.com
Fri Jul 10 13:13:42 EDT 2015


Time is also  often a cog a11y issue so it's good you dropped it

Re inactivity,  what if user is watching a dvd or listening to a podcast
for a long time?

Steve Lee
Sent from my mobile device Please excuse typing errors
On 10 Jul 2015 17:55, "Kasper Markus" <kasper at markus.dk> wrote:

>  Hi Everyone,
>
> We talked some more about the multi-user/conflict resolution scenario at
> the Copenhagen hackathon, and found the timer scenario (user has to log in
> within a certain amount of time) has some problems. One of these is the
> problem in terms of demoing, having to do something within a fixed amount
> of time/unpredictable behavior of the system due to the timer.. But more
> importantly, imagining a blind person, or someone who is paralyzed having
> to find and log into the system within eg. 20 seconds seems problematic in
> a lot of ways.
>
> After some discussion, we found that a more 'stable'/inclusive alternative
> would be the following implementation:
>
>    - If a new user logs in, when another user is already logged in, the
>    system will try to adjust to accomodate both users. In other words: if user
>    A keys in the system will adjust to him/her. If user B then keys in at any
>    time before A logs out, this is considered a dual user login and the system
>    will adjust for both.
>    - To avoid the situation where a user A forgets to log out and the
>    system becomes unusable for all following users, a special token/NFC can be
>    used to log any current user out.
>    - In the longer term, we are planning to hook up to the OS systems
>    inactivity timer, logging a user out once this inactivity timer runs out
>    (with a warning for them to cancel the logout, of course). This is beyond
>    the scope of cloud4all.
>
> This is still not ideal - but until we hook up to the OS' inactivity
> timer, etc., whichever solution we pick will be suboptimal - but we think
> this one seems the most appealing in the shorter term.
>
> Cheers,
> ~Kasper
>
> _______________________________________________
> Architecture mailing list
> Architecture at lists.gpii.net
> http://lists.gpii.net/cgi-bin/mailman/listinfo/architecture
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gpii.net/pipermail/architecture/attachments/20150710/5adff708/attachment.html>


More information about the Architecture mailing list