> >> * It's unclear when you've been signed out due to inactivity. > Please > >> add an alert for this - otherwise it's very confusing when buttons > >> disappear. > > > > Yes some kind of obvious indicator would be good but please don't > resort to > > a modal dialog for this as WSAS did! I hate that... > > Why? This is one of the few times I think a modal dialog is totally > appropriate, since knowing if you're "you" or not totally affects the > way you deal with the site. The model that I think works best is what > I've seen on bank sites - put up a modal dialog which says "your > session > is about to time out; click ok if you want to keep working". If you > don't click on it within 1m or whatever, you get redirected to the home > page, logged out.
Well, perhaps I spoke too soon. Here's my reasoning, see which model you think applies here. An "about to expire" dialog is entirely separate. There are two cases to consider - one where viewing a page is itself a secure activity. A bank is an example of this case. Essentially reading and writing both require authorization. The other is that certain permissions aren't available but the page is basically sound. The Mashup Server is an example of this case - if you're not logged in you can't post a comment for instance. In this case reading doesn't require authorization or authentication, just writing. In the first case, modal is entirely appropriate. But the mode needs to be to redirect you to another page. WSAS puts up a modal dialog, preventing you from doing anything with the page, yet still allows you to see the page, try to click on the dead links, and otherwise get frustrated. All you can do in fact is go to the login page - so why not just take the user there in the first place? I can think of only a very few situations where a web page should bring up a modal dialog instead of a redirect - all centering around ensuring that the user doesn't lose any unsaved work. In the second case, the switch from a read-write mode to a read-only mode should not cause a significant interruption in the work flow. The user needs to be aware he needs to log in again if he wants to engage in writing, but he could also just proceed with some read-only tasks. There are two choices - continue working, or sign in again. Since we have a sign-in link available, the user can make those two choices without a modal dialog or a redirect. We just have to highlight on the page that his sign-in status has changed. I'd imagine something that doesn't take up a lot of real-estate but catches the eye. Like a bubble on the sign-in link noting that the user has been signed out, or some kind of animation. Give me <blink> ;-). > >> * At present it looks like you can tag anonymously. I think we > should > >> remove that and only allow tags from signed-in users. > > > > +1. I'd also be interested in seeing if you have a role-based > mechanism for > > determining who's authorized to remove a tag. I'm currently > calculating > > based on ownership. > > "You", i.e. the Mashup Server, shouldn't need to be calculating this at > all, right? It's all the Registry. Are you talking about "caculating" > for UI purposes, to figure out if the button should be displayed? Yes. > It should be a) the owner of a given resource can always remove tags, > and b) admins can also. If you want to add a notion of a "remove tags" > permission that you can grant to other users/roles as well, that seems > ok (but maybe unnecessary). I check who's logged in, whether they created the tag (in which case they can remove their application of it) or whether the tag is on a resource owned by the current user (in which case they can remove all applications of it), or the current user is an admin (in which case they can remove all applications of it). This calculation is done by the mashup server, and hopefully matches the permissions of the mashup, but it would be nicer to user the permissions as the authority on whether the current user can remove the tag. > Thanks, > --Glen > > _______________________________________________ > Registry-dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/registry-dev _______________________________________________ Registry-dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
