On 2014-05-21 23:00 +0000, Dan Wells <d...@calvin.edu> wrote: > I'm not quite sure how to answer because I feel like we're not asking > the right question. Rather than ask how links should behave, we might > instead ask, what should be a link? And also perhaps the inverse; in > our interface, what should a link be? [snip] > My sense, though, is that you were not really asking about external > links which might exist in our content, but rather "internal" links > (which I will define as a link to a new context in the staff client). > These are trickier. To help our thinking, I wish to posit that on any > given screen, we have both a context and a state. The URL always > captures the context, and sometimes some aspects of the state, but we > cannot expect it to always capture every aspect of the current state. > Because of this fact, every time you switch contexts, you risk losing > some state. Therefore, we should be very careful to offer any > interface element, link or otherwise, which switches context without a > clear indication to the user of that intention. [snip] > Instead of thinking of things as 'links' and then trying to make one > rule for a bunch of disparate things, I'd propose that we should have > distinctive interface elements for which we can then define usage > appropriate behaviors. Doing so would create a tremendous opportunity > for improving the overall usability of the staff client as a whole. > > I could say more, but I've said a lot already. I'd love to hear > reactions to what I've said so far (which I know is very uneven given > the time and space limitations). Am I way off-base? Or is this the > beginning of something we can work with?
Dan, I share your concern (although I would never have been able to articulate it so well!), and I think you've presented us with a good way of thinking about the issue. In general I like the idea of letting the user choose how a link opens. But I don't think that behavior is always appropriate in a web app, where context and state are richer, and user behavior more constrained, than they are on a simple web page. > P.S. Bill, I think you are doing an outstanding job, and we couldn't > even have this conversation without all the work you have done to pave > the way. Please don't take anything above as being critical of the > hundreds of decisions you've had to make to get to where we are today. > Again, thank you! This probably isn't said often enough. Thanks for all your hard work on the new client, Bill! I've been really impressed and pleased by the development so far. -- Jeff Davis Lead Evergreen Specialist BC Libraries Cooperative