no search box on catalog's account pages when viewed on screens smaller than 600px wide

I think this was altered in the mobile view of the my account because people in the group felt that when going to my account people actually were looking to interact with my account areas and having half the screen used up with the search box and filters was overkill.

While not explicit, the upper left logo is linked back to basic search to give patrons a consistent way back to searching by clicking on the logo for the catalog. This was the most common approach undertaken by all the libraries in the group discussion to revert back to a new search, so it was applied as a default behavior.

So, maybe something we need to address with more explicit wording on the screen or better navigation in general for the mobile view? Depends on how sites customize or not for this area.

I have to say I thought this was a feature, not a bug, just as Ben said. Our C/W MARS logo links back to basic search. I'm not sure how we'd address this specifically in the mobile view.

Added links for Basic, Advanced, and Browse to the top of all the my account screens. Uses a CSS class only visible in mobile (less then 600px) view.

Working Branch is
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/spaterno/lp_1261791_mobile_myacct_search

I like the idea of links directing the patron back to a search. I tested Suzanne's patch on a fresh install of master, it worked, but the links are the same color as the background. One solution might be to add a class to the links and a color definition in CSS?

We have had a look at this at MVLC, and the staff member who reported the problem to us said, "I think it's great."

We did not Garry's issue because we tested on a system with custom css in place.

I agree that css classes should be added to the search links. Using id selectors for the ids of the spans or links themselves would be preferable to classes in my opinion, mainly because the links and spans have already been given the ids.

I added a new class to the label and links to pull a new color type from the colors file,set to white in the stock screens. This way libraries can configure the color for their own mobile skin. Using the same class/color as the non-mobile view wouldn't work in all cases, as the links appear in between the header and the content wrapper.

I have just started using git so I am having some trouble getting the changes pushed to the working branch, but I'll add the link as soon I can.

I was able to get the changes I made to fix the label color pushed to working.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/spaterno/lp_1261791_mobile_myacct_search

I have had a look at the branch and loaded it on my development server.

The question that comes to my mind when I look at these changes is why was a new color variable added to colors.tt2? Why not just use an existing, appropriate color?

I ask because we have already customized our existing colors and without customizing the new color, the links do not show up in our catalog because our background is white. Had an existing color been chosen such as the default button or text color, the links would have shown up without us having to add any existing customizations.

I added a new color because I wasn't able to find an appropriate one for the type of text it was from the ones that existed in order to make it work in the out of the box solution and our own install, which also has a white background.

In the mobile view the text falls outside the bounds of the header and before the content wrapper. It basically shows up where the topnav does in the full screen view. I thought that part of the page might be used as a nav type bar with a background color in some libraries, which is why I gave it a new color in the colors.tt2 file.

If it's better not to use a new color, that can be taken out. Based on the names of the existing colors I didn't see any that would work both for people who have already customized and the out of the box Evergreen.

I took a look at the catalog from a clean install and at a customized catalog with a white header (mostly MVLC's, but also NOBLE's) to see if there was an existing color that could be used and work both in systems with color in the header and those that use white.

What I think we need is to use a class for text that is also used in the header. But the thing is, we don't typically use text there. And the reason why the links are located in the header is because it seems better usability-wise for those links to appear above that dropdown menu that is used in a mobile view.

I "thought" I found a potential candidate when I noticed that the name of a logged-in user displays in the header when the catalog is in mobile view. However, I found an additional problem. Although this name displays properly in the clean install catalog, it is invisible in the catalogs with a white header. In a non-mobile view, the white text is visible because there is a background-color applied to the dash-wrapper id. However, that background color is removed in mobile view, leaving the text invisible for sites that use a white header.

So I think I agree with adding a new color to handle text that is in the header (we may make use of that color with some still-unknown future feature that adds text to the header). I also think we need another bug report that deals with the name issue either by keeping that background color when in mobile view (might look funny) or by somehow using a different color (perhaps the new header color) for the name when it's in mobile view.

Well, OK, then. I can see why a new color variable may be necessary.

I've got no problem with this going in, but I'll give others a chance to look at it and chime in.

We'll need to adjust our customizations to take the new color into account, and perhaps a release note entry should be added to that effect.

I modified the name of the color I created to "mobile_header_text". Now the name is more generic and can be used for any text put into the mobile header.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/spaterno/lp_1261791_mobile_myacct_search

I've signed off on Suzanne's commit, added a release note entry, and added a commit to make a small adjustment to the background color. The shade of green behind the links was slightly different than the background color for the rest of the header.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/lp_1261791_mobile_myacct_search

I also would like to hear feedback from others on the new color variable. Also, does the new color variable push it into new feature territory as opposed to bug fix?

I pulled the other commits from Kathy's branch in and then moved the release note into the appropriate place for RELEASE_NOTES_2_7.txt.