Re: [OPEN-ILS-GENERAL] Web Client Design - Fixed Page Elements?

[Boyer, Jason A]

I like this idea a lot, and I have a thought on how to avoid wasting a lot of 
vertical space while doing it. I don't know how complex it would be since I 
haven't looked at the angular code much, but if the save/cancel options could 
take the place of the Check Out, Items Out, etc. options at the top that 
wouldn't require any additional space. It would also make it clear that you've 
chosen to edit this record and to move on to something else you need to either 
choose to save it or abandon your changes. I would even go so far as to say 
that I'd like to adopt the Android and iOS convention that the "data-loss" 
(Cancel in this case) option be red while the Save option be blue like the 
other interface elements. It's something I could see used in several places 
(and possibly make the angular-ization of any interface that doesn't follow 
this convention more desirable, possibly getting more hands involved, etc.)

Jason

--
Jason Boyer
Indiana State Library
http://library.in.gov/

From: Open-ils-general 
[mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Dan 
Wells
Sent: Friday, July 10, 2015 3:14 PM
To: 'open-ils-general'
Subject: [OPEN-ILS-GENERAL] Web Client Design - Fixed Page Elements?

Hello all,

This came up in Kathy's recent thread asking about the patron editor, and 
rather than hijack that thread, I'd like to broaden the conversation a little, 
because the same usability issues will affect many areas of the staff client.

To cut straight to the point, I strongly believe that using fixed position for 
large portions of the staff client interface will have a major positive effect 
on usability.  This has been applied and proven in desktop applications for 
decades, and is now being rediscovered within the browser environment as web 
"pages" become applications.  There is plenty of evidence out there to support 
this stance, but here is a quick read which highlights the point well: 
http://www.smashingmagazine.com/2012/09/11/sticky-menus-are-quicker-to-navigate/

If we consider the mockups from our design internship a few months back, in the 
screenshot Kathy referenced, the entire top area (and, in this case, the right 
sidebar) would ideally be fixed position.  The only scrolling area should be 
the actual form.  For any who attended my talk on design at the conference, 
this is exactly the concern of rule of thumb #3: "Scroll the data, not the 
interface", with "data" broadly including all information and workspaces which 
are not "the program".  (Here is Kathy's screenshot link again for reference: 
http://media.tumblr.com/69beec7802a938b889bdfa80c7e0d54b/tumblr_inline_nkn0okinXl1t572gy.png
 )

The main complaint driven at fixed screen elements is that they take up too 
much space.  They do take up space, obviously, but with the amount of use these 
elements get on a moment by moment basis, the space is well worth taking.  In 
cases where more workspace is truly of benefit, we are better off using fixed 
position with a "hide" option (auto or manual) than we would be with using 
scroll, as we can retain the clear benefits of persistent availability and 
predictability.  (Expert users might also choose to do without some toolbars 
and rely on keyboard shortcuts, but that sort of use will never be feasible for 
many staff client users and scenarios.)

As the Smashing Magazine article points out, the easiest way to understand the 
situation is to simply imagine other software working with fully-scrolling 
interfaces.  In this imaginary scenario, when you are using a word processor, a 
spreadsheet application, or even a browser itself, all of your menus, toolbars, 
tabs, etc., would simply scroll off the screen as soon as you tried to scroll 
down to see additional content.  It's likely that some ancient desktop software 
did exactly that, but if they did, they are now extinct, and not without good 
reason.

Another valid concern sometimes raised is the effect a rich, fixed interface 
might have on a small screen appliance, like a phone.  This topic should be 
addressed, but I believe it is best kept separate from the problems at hand, 
which are already large enough.  My personal stance would be that a full, 
first-class staff client interface on a small screen device is not a realistic 
concern for a community of our size, needs, and capabilities.  Our bar for 
using the full client on phones should be "not impossible", and then we can 
re-dedicate a portion of our energy to creating limited, purpose-built 
interfaces for functions of known value on small devices (e.g. inventory 
scanning), and which are also likely to best include some fixed top and/or 
bottom elements.

I also want to emphasize that none if this is meant to disparage the work which 
has been done so far.  It is much harder to make something out of nothing than 
to take something and make it better.  I also acknowledge that, while I have 
spent large amounts of time studying the web client, I have found ze

[OPEN-ILS-GENERAL] Historical Circulation Retention Age

[Joan Kranich]

Hi,

Is anyone using the Global Flags Historical Circulation Retention Age and 
Historical Circulations Per Copy to age circulations?

If you are using this have you found any problems?  C/W MARS is planning to 
start this process and is interested in any experience you can share.

Thanks.

Joan

Joan Kranich
C/W MARS Member Services
jkran...@cwmars.org
508-755-3323 ext. 21

Re: [OPEN-ILS-GENERAL] Web Client Design - Fixed Page Elements?

[Ruth Frasur]

I have nothing valuable to add to this.  I will say that I agree with both
Dan and Mike (and by extention, Kathy and Jason), and I'm not sure where
the middle point is.  Mostly, I just want to say Thank You to all of your
struggling with this.  What comes out of this struggle will be fantastic.

On Mon, Jul 13, 2015 at 8:23 AM, Boyer, Jason A 
wrote:

>  I like this idea a lot, and I have a thought on how to avoid wasting a
> lot of vertical space while doing it. I don’t know how complex it would be
> since I haven’t looked at the angular code much, but if the save/cancel
> options could take the place of the Check Out, Items Out, etc. options at
> the top that wouldn’t require any additional space. It would also make it
> clear that you’ve chosen to edit this record and to move on to something
> else you need to either choose to save it or abandon your changes. I would
> even go so far as to say that I’d like to adopt the Android and iOS
> convention that the “data-loss” (Cancel in this case) option be red while
> the Save option be blue like the other interface elements. It’s something I
> could see used in several places (and possibly make the angular-ization of
> any interface that doesn’t follow this convention more desirable, possibly
> getting more hands involved, etc.)
>
>
>
> Jason
>
>
>
> --
>
> Jason Boyer
>
> Indiana State Library
>
> http://library.in.gov/
>
>
>
> *From:* Open-ils-general [mailto:
> open-ils-general-boun...@list.georgialibraries.org] *On Behalf Of *Dan
> Wells
> *Sent:* Friday, July 10, 2015 3:14 PM
> *To:* 'open-ils-general'
> *Subject:* [OPEN-ILS-GENERAL] Web Client Design - Fixed Page Elements?
>
>
>
> Hello all,
>
>
>
> This came up in Kathy’s recent thread asking about the patron editor, and
> rather than hijack that thread, I’d like to broaden the conversation a
> little, because the same usability issues will affect many areas of the
> staff client.
>
>
>
> To cut straight to the point, I strongly believe that using fixed position
> for large portions of the staff client interface will have a major positive
> effect on usability.  This has been applied and proven in desktop
> applications for decades, and is now being rediscovered within the browser
> environment as web “pages” become applications.  There is plenty of
> evidence out there to support this stance, but here is a quick read which
> highlights the point well:
> http://www.smashingmagazine.com/2012/09/11/sticky-menus-are-quicker-to-navigate/
>
>
>
> If we consider the mockups from our design internship a few months back,
> in the screenshot Kathy referenced, the entire top area (and, in this case,
> the right sidebar) would ideally be fixed position.  The only scrolling
> area should be the actual form.  For any who attended my talk on design at
> the conference, this is exactly the concern of rule of thumb #3: “Scroll
> the data, not the interface”, with “data” broadly including all information
> and workspaces which are not “the program”.  (Here is Kathy’s screenshot
> link again for reference:
> http://media.tumblr.com/69beec7802a938b889bdfa80c7e0d54b/tumblr_inline_nkn0okinXl1t572gy.png
> )
>
>
>
> The main complaint driven at fixed screen elements is that they take up
> too much space.  They do take up space, obviously, but with the amount of
> use these elements get on a moment by moment basis, the space is well worth
> taking.  In cases where more workspace is truly of benefit, we are better
> off using fixed position with a “hide” option (auto or manual) than we
> would be with using scroll, as we can retain the clear benefits of
> persistent availability and predictability.  (Expert users might also
> choose to do without some toolbars and rely on keyboard shortcuts, but that
> sort of use will never be feasible for many staff client users and
> scenarios.)
>
>
>
> As the Smashing Magazine article points out, the easiest way to understand
> the situation is to simply imagine other software working with
> fully-scrolling interfaces.  In this imaginary scenario, when you are using
> a word processor, a spreadsheet application, or even a browser itself, all
> of your menus, toolbars, tabs, etc., would simply scroll off the screen as
> soon as you tried to scroll down to see additional content.  It’s likely
> that some ancient desktop software did exactly that, but if they did, they
> are now extinct, and not without good reason.
>
>
>
> Another valid concern sometimes raised is the effect a rich, fixed
> interface might have on a small screen appliance, like a phone.  This topic
> should be addressed, but I believe it is best kept separate from the
> problems at hand, which are already large enough.  My personal stance would
> be that a full, first-class staff client interface on a small screen device
> is not a realistic concern for a community of our size, needs, and
> capabilities.  Our bar for using the full client on phones should be “not
> impossible”, and then we can re-dedicate a portion of our e

[OPEN-ILS-GENERAL] Hours of library open / close

[Walz, Jennifer]

All -

  We are an academic library and the library hours change from "during the 
semester" to "summer" to "holiday" hours.

  Is there any way to have several Org unit calendars where we can switch 
easily between these things? Our general open / close times are during the 
semester and that does cover most of the year, but the other set times it would 
be nice to have a block calendar change for the whole org unit.

Any ideas?  Thoughts?

Thanks!

Jennifer
--
Jennifer Walz, MLS - Head of ILS changes
Kinlaw Library -  Asbury University
One Macklem Drive, Wilmore, KY 40390
859-858-3511 ext. 2269
jlw...@asbury.edu

Re: [OPEN-ILS-GENERAL] Hours of library open / close

[Ben Shum]

Hi Jennifer,

I've often wondered about this myself since some of our libraries also
have periodic shifts to "summer" hours, or even "renovation" hours of
service as they go through lifecycles.  So yes, it seems like your
idea might prove to be a helpful one to even public libraries, not
just academic libraries.

I can't commit to anything new at this time, but maybe you or others
might find this to be a worthy contender for feature development in
future Evergreen releases.  Certainly sounds like a good wishlist idea
anyways.

-- Ben

On Mon, Jul 13, 2015 at 4:51 PM, Walz, Jennifer  wrote:
> All –
>
>
>
>   We are an academic library and the library hours change from “during the
> semester” to “summer” to “holiday” hours.
>
>
>
>   Is there any way to have several Org unit calendars where we can switch
> easily between these things? Our general open / close times are during
> the semester and that does cover most of the year, but the other set times
> it would be nice to have a block calendar change for the whole org unit.
>
>
>
> Any ideas?  Thoughts?
>
>
>
> Thanks!
>
>
>
> Jennifer
>
> --
> Jennifer Walz, MLS - Head of ILS changes
> Kinlaw Library -  Asbury University
> One Macklem Drive, Wilmore, KY 40390
> 859-858-3511 ext. 2269
> jlw...@asbury.edu
>
>



-- 
Benjamin Shum
Evergreen Systems Manager
Bibliomation, Inc.
24 Wooster Ave.
Waterbury, CT 06708
203-577-4070, ext. 113

Re: [OPEN-ILS-GENERAL] Hours of library open / close

[Rogan Hamby]

We have several public systems with variant summer hours so I agree it
would have broader appeal than just academic libraries.

On Monday, July 13, 2015, Ben Shum  wrote:

> Hi Jennifer,
>
> I've often wondered about this myself since some of our libraries also
> have periodic shifts to "summer" hours, or even "renovation" hours of
> service as they go through lifecycles.  So yes, it seems like your
> idea might prove to be a helpful one to even public libraries, not
> just academic libraries.
>
> I can't commit to anything new at this time, but maybe you or others
> might find this to be a worthy contender for feature development in
> future Evergreen releases.  Certainly sounds like a good wishlist idea
> anyways.
>
> -- Ben
>
> On Mon, Jul 13, 2015 at 4:51 PM, Walz, Jennifer  > wrote:
> > All –
> >
> >
> >
> >   We are an academic library and the library hours change from “during
> the
> > semester” to “summer” to “holiday” hours.
> >
> >
> >
> >   Is there any way to have several Org unit calendars where we can switch
> > easily between these things? Our general open / close times are
> during
> > the semester and that does cover most of the year, but the other set
> times
> > it would be nice to have a block calendar change for the whole org unit.
> >
> >
> >
> > Any ideas?  Thoughts?
> >
> >
> >
> > Thanks!
> >
> >
> >
> > Jennifer
> >
> > --
> > Jennifer Walz, MLS - Head of ILS changes
> > Kinlaw Library -  Asbury University
> > One Macklem Drive, Wilmore, KY 40390
> > 859-858-3511 ext. 2269
> > jlw...@asbury.edu 
> >
> >
>
>
>
> --
> Benjamin Shum
> Evergreen Systems Manager
> Bibliomation, Inc.
> 24 Wooster Ave.
> Waterbury, CT 06708
> 203-577-4070, ext. 113
>


-- 

Rogan Hamby, MLS, CCNP, MIA
Managers Headquarters Library and Reference Services,
York County Library System

“You can never get a cup of tea large enough or a book long enough to suit
me.”
― C.S. Lewis 

Re: [OPEN-ILS-GENERAL] Hours of library open / close

[McCanna, Terran]

We have a number of libraries that have unusual operating hour patterns that 
the current system doesn't accommodate. Some have seasonal differences, some 
are open every other Saturday, some are on a skeleton crew so are open some 
days in two shifts (4 hours in the morning, for hours in the evening, but 
closed for a couple of hours in the middle type of thing). 

On a related topic, if the operating hours were not part of the org unit 
settings, but were in a different area that we could allow the libraries to 
update (perhaps in the library settings editor, or in a different area 
entirely), it would be a lot easier to keep up to date.

Now that the library pages with the hours and contact info are available, it 
would be really nice to at least have a notes field where we could add notes 
specific to a particular library's hours. It would also be nice for it to 
display upcoming scheduled closures from the Closed Dates Editor. 


Terran McCanna 
PINES Program Manager 
Georgia Public Library Service 
1800 Century Place, Suite 150 
Atlanta, GA 30345 
404-235-7138 
tmcca...@georgialibraries.org 
- Original Message -
From: "Ben Shum" 
To: "Evergreen Discussion Group" 
Sent: Monday, July 13, 2015 7:19:57 PM
Subject: Re: [OPEN-ILS-GENERAL] Hours of library open / close

Hi Jennifer,

I've often wondered about this myself since some of our libraries also
have periodic shifts to "summer" hours, or even "renovation" hours of
service as they go through lifecycles.  So yes, it seems like your
idea might prove to be a helpful one to even public libraries, not
just academic libraries.

I can't commit to anything new at this time, but maybe you or others
might find this to be a worthy contender for feature development in
future Evergreen releases.  Certainly sounds like a good wishlist idea
anyways.

-- Ben

On Mon, Jul 13, 2015 at 4:51 PM, Walz, Jennifer  wrote:
> All –
>
>
>
>   We are an academic library and the library hours change from “during the
> semester” to “summer” to “holiday” hours.
>
>
>
>   Is there any way to have several Org unit calendars where we can switch
> easily between these things? Our general open / close times are during
> the semester and that does cover most of the year, but the other set times
> it would be nice to have a block calendar change for the whole org unit.
>
>
>
> Any ideas?  Thoughts?
>
>
>
> Thanks!
>
>
>
> Jennifer
>
> --
> Jennifer Walz, MLS - Head of ILS changes
> Kinlaw Library -  Asbury University
> One Macklem Drive, Wilmore, KY 40390
> 859-858-3511 ext. 2269
> jlw...@asbury.edu
>
>



-- 
Benjamin Shum
Evergreen Systems Manager
Bibliomation, Inc.
24 Wooster Ave.
Waterbury, CT 06708
203-577-4070, ext. 113