Re: [CODE4LIB] Formalizing Code4Lib?

[Chris Moschini]

Having been through something like this in the past that went very badly, a
small bit of advice:

If the impetus for forming a company is protection from liability for the
Annual Conference, form it solely for that purpose.

Leaving it open-ended will bring in everyone's ideas. Many of them will
conflict. That will breed sharp disagreements. With a company in the wings
you have money on the line increasing the negative impacts available here.

Some companies have a very clear singular charter to prevent this and I
recommend constraining this one likewise, so everyone/anyone involved is
aware of and expecting just that one purpose. That will give it clear
direction and improve its chance at success.

Re: [CODE4LIB] JPEG question

[Chris Moschini]

DPI is suspicious. Guessing both exports treated the input as 150dpi on the
way in regardless of real DPI. Check the resolutions on the >1500dpi images
- to convert for example 1500dpi to 150dpi without losing data you need to
go up 10x in pixels, so for example 200 pixels to 2000. If it didn't you've
got your culprit.

PDF mid-step sounds a little like it should be removed from your process if
possible. Worst-case you may even have a step along the way here that
treats everything as 72dpi regardless of real input - plenty of image
converters out there that ignore dpi entirely.

Re: [CODE4LIB] Let's Encrypt and EZProxy

[Chris Moschini]

Cornel Darden wrote:

> Hello,
>
> SSL certificates are a pain. Should there be a non-profit organization,
> like a library, that can issue free trusted certficates? Should they still
> cost?
>

That's what letsencrypt is, which is what this thread is about.

https://letsencrypt.org/

Re: [CODE4LIB] Best way to handle non-US keyboard chars in URLs?

[Chris Moschini]

On Feb 20, 2016 9:33 PM, "Stuart A. Yeates"  wrote:
>
> 1) With Unicode 8, sign writing and ASL,  the American / international
> dichotomy is largely specious. Before that there were American indigenous
> languages (Cheyenne etc.), but in my experience Americans don't usually
> think of them them as American.

It's not about the label, so don't get too hung up on that. It's about
what's easy to type on a typical US keyboard.

> 2) Google and friends are more than capable of handling redirects, even
> when done badly.

Google punishes redirects actually. #38 here:

https://blog.kissmetrics.com/penalized-by-google/

But you can find plenty more discussion of the redirect penalty. Not
redirecting would mean duplicate content which is also punished - see #3.

> 3) Who type un-shortened URLs any more?

I'm looking for responses that solve this rather than dismiss Intuitive
URLs.

For example a bunch of random chars or an ID for each url guarantees
uniqueness, but it's much less useful to the user. It looks like nonsense
and you won't be recalling it later. You're not going to be able to
describe the url to someone else, and if you IM it to someone or they see
it on another website the link gives them little confidence that click will
get them what's promised.

https://www.deepcrawl.com/knowledge/best-practice/guide-to-url-design/

[CODE4LIB] Best way to handle non-US keyboard chars in URLs?

[Chris Moschini]

Curious how others have handled this, as I'm sure those on this list have
dealt with this.

Any site that has mixed English/non-English content will quickly run into
this issue:

Page has a name like:

Bob

Intuitive URLs are nice, we'll put it at:

/bob

Page has a name like:

Itajaí Cêrebro Raízes

OK... should that be:

/itajai-cerebro-raizes
/itajaí-cêrebro-raízes
/itaja-crebro-razes

The first being easy for US-English users to type on a keyboard, and, valid
in all URI specs.

The second being the actual name, and valid in the HTML5 URI spec, invalid
in the original URI spec, and will break old browsers like anyone on old
enough versions of Internet Explorer. And, a US-English user probably
doesn't know how to type it.

The third being a naive "Remove anything that isn't on a US English
keyboard" (regex /[^/w/d]/), works for everyone, simplest to code, least
intuitive.

The challenge isn't over yet. How about:

עםמק שבםודאןב

What should that URL be? /עםמק-שבםודאןב? And note that this is a
right-to-left language, so in a sense just having the URL read left to
right until this name is a bit Amerocentric on its own. Zero chance a US
English keyboard user will have any idea how to type that, and, they're
unlikely to recall it when sharing in a conversation either.

I've seen 3 opinions and I dislike all of them:

1) Be Amerocentric like the old days. Just mush everything down to US
keyboard chars and when there aren't any, give it an ID number.

2) Be open. Use it as-is and if someone can't type it well, there's always
Google, and the page might not be in their language anyway so maybe that
content isn't for them.

3) Do both. Accept both above URL approaches:
3a) ...and redirect to Amerocentric URL
3b) ...and redirect to international URL
3c) ...and don't redirect

The problem with 1 is obvious.

The problem with 2 is "That content isn't for them" is a false assertion.
That Hebrew name above comes from an actual site, about an event in an area
for primarily English speakers.

The variations in 3 all have issues:

3c breaks SEO rules. You are supposed to have a single canonical URL for
each page and each piece of content on your site, or else you're going to
frustrate users looking for your content with multiple results for the same
thing - or more likely, Google will punish you by pushing all of your
frustrating results down and users will never find you.

3a and 3b break Web Performance rules, especially on mobile. A Redirect is
a great way to ruin page load time. Presumably within your site you'd
always link to the canonical URL, so those visiting the non-canonical will
typically coming in from the outside. Wasting their time with a redirect is
a good way to turn users away from your slow site.

Interested to hear if there's a 4th, best option.

Re: [CODE4LIB] Responsive website question

[Chris Moschini]

I'm also torn on this issue. It's safe to conclude that for many users,
Responsive has broken the Zoom button. That's a strict no-no - don't break
fundamental features of the browser. Yet Responsive is essential to dealing
with a wide range of devices.

Worse, it's hard to tell what the user intended.

If I have my browser always set to zoom 200%, it's probably because I've
got bad eyes and want to see everything larger - fonts, images with text in
them, logos, icons presented as images - all of it - not just a font zoom.
If that means the Responsive code on the page presents it all to me like
Mobile so I don't have a horizontal scroll, that seems ideal.

But if I hit the Zoom feature while the page is open, I'm probably trying
to zoom in on something specific. Two problems, one minor one major:

1) The site reflows, confusing me. Some sites look dramatically different,
some less so.

2) If I've scrolled down at all, the reflow is going to throw the content
I'm focused on downwards, or at times, upwards, depending on how it was
coded. Bootstrap even includes things like hidden-xs, which people often
use to hide sidebars. If I was trying to zoom in on the content of a
sidebar, it might scurry down the page then vanish on me entirely as I
zoom. Definitely not what I wanted.


So it seems the right answer is to present the user with a reflowed site if
they land on the page already zoomed, but after that, respond to zooming by
not reflowing at all. Has anyone done this?

I looked at Katherine's brilliant proposed fix, but it doesn't do it - the
site linked to there actually has the fix implemented and, well, it doesn't
fix it. Zoom still reflows.

I think this is a problem for Bootstrap especially, since it's the most
widely-in-use Responsive library, uses pixel-width media queries, and
exhibits this problem. Sadly this was reported as a bug in 2012 and as so
often happens in open source, the maintainers responded essentially, "This
isn't what I want to do" https://github.com/twbs/bootstrap/issues/2002

If no one's done it here's how I'd propose coding it:

1) Replace all media queries for sizing, something like this:

@media (min-width: 720px) {
  >720px styles go here

Becomes:

body.minWidth720 {
  >720px styles go here

Then apply js to the page. You'd place a very small amount in the head (bad
for performance but essential for preventing a FOUC) that measures window
width and applies the relevant classes to the body tag.

Then at the end of the body tag, more Javascript listens for resizes and
responds by swapping the body classes. Since zoom doesn't trigger resize*
on most devices, you'd still get the site to reflow nicely, when for
example someone rotates a smartphone from 720 wide to 1280 wide, but when
they zoom, nothing would reflow (since it was set in stone by the js in the
head).

Thoughts?

*Not tested, need to verify - if it does trigger resize though the solution
is to attempt to detect whether it's a zoom click vs browser drag/rotate.

Re: [CODE4LIB] [patronprivacy] Let's Encrypt and EZProxy

[Chris Moschini]

Andrew, great analysis.

So, letsencrypt and EFF have an obvious goal here, and these vendors are in
the way. There's a noble purpose here, so what can we do to move vendors
towards it? Perhaps if there was a Kickstarter for someone or a team to:

1) Determine the top vendors in this space, by usage.
2) Pick say the top 50 and analyze exactly what if anything they're doing
that gets in the way, for example these DJ stanzas.
3) Name and Shame.

That would hopefully be enough to move the majority of those vendors
towards patches. Possibly a consulting approach for those that don't move.

Think that'd help? Think it'd have traction?



On Sat, Jan 16, 2016 at 3:25 AM, Andrew Anderson  wrote:

> On Jan 15, 2016, at 13:20, Salazar, Christina 
> wrote:
>
> > Something that I also see implied here is why aren’t vendors doing a
> better job collaborating with the developers of EZProxy, instead of only
> putting the pressure on Let’s Encrypt to support wildcard certs (although I
> kind of think that’s the better way to go).
>
>
> Because it’s easier than actually taking the time to fully understand the
> platforms and how all the pieces fit together.
>
> I’ve lost track of how many discussions I have had with various vendors
> recently over:
>
> * Why they need to encode URLs before trying to pass them to another
> service like EZproxy's login handler
> * Why they really do need to pay attention to what RFC 2616 Section 3.2.2
> and RFC 2396 Section 2.2 have to say regarding the use of the reserved
> character in URLs
> * Why it’s a bad idea to add “DJ google.com” in the EZproxy stanza
> * Why it’s a bad idea to add “DJ ” in the EZproxy stanza
> * Why it’s a bad idea to add “DJ ” in the EZproxy
> stanza
>
> Instead of trying to understand how proxied access works, someone just
> keeps slapping “DJ ” or “HJ ” into the service
> stanza until the service starts working, and then never revisits the final
> product to see if those additions were really necessary.  Do this for a few
> platform iterations, and the resulting stanza can become insane.
>
> The conversations typically go something like this:
>
> Me: “Why are you trying to proxy google.com services?”
> Vendor: “Because we’re loading the jQuery JavaScript library from their
> CDN."
> Me: “And how are you handling registering all your customer’s IP addresses
> with Google?”
> …  …
> Vendor: “We don’t”.
> Me: “Then why do you think you need that in your proxy stanza?”.
> …  …
> Vendor: “We . . . don’t?”
> Me: “Exactly. And how are you reaping the performance benefits of a CDN
> service if you’re funneling all of the unauthenticated web traffic through
> a proxy server instead of allowing the CDN to do what it does best and
> keeping the proxy server out of the middle of that transaction?"
> Vendor: “We . . . aren’t?”
> Me: “That’s right, by adding ‘DJ ’ to your stanza, you have
> successfully negated the performance benefits of using a CDN service.”

Re: [CODE4LIB] A smart bulk file name editor?

[Chris Moschini]

It won't surprise you coders do this all the time and so there are 80 ways
to do this, so your peril is choice not scarcity.

Although there are a ton of tools that will do this for non-coders:
https://www.google.com/webhp?q=file%20renamer

On Windows robocopy is popular.

The truth is though most coders just pick the programming language of their
choice and go for it. The most common is Bash and regex. Bash is built-in
to Linux and Macs and pretty easy to  get
onto Windows . It's an old and ugly language but
it's also the kitchen sink of "I just need to do this quick thing." That
said if you dislike old and ugly languages or unintuitive syntax or command
names, pick a programming language you do like, or one of the tools above.


On Fri, Jan 15, 2016 at 10:56 AM, Amy Schuler 
wrote:

> Hi,
> I'm looking for a smart bulk file editor, if it exists.  Specifically I'd
> like it to be able to move through a list of PDF files that are published
> research papers, and rename them in this approximate format, based on the
> contents of the file:
> firstauthor_firstfewwordsoftitle_year.pdf
>
> I know this is probably a crazy dream.  The bulk file editors that I know
> about are more simple.  They can bulk rename files according to a pre-set
> pattern or they just remove/add/re-position bits from the existing file
> string.
>
> Thanks!
>
> Amy Schuler
> Cary Institute of Ecosystem Studies
> schul...@caryinstitute.org
>

Re: [CODE4LIB] yaml/xml/json, POST data, bloodcurdling terror

[Chris Moschini]

Well, if you mean "terrified" as in "Ought to learn about security and
input sanitization," I agree. If you mean it as in "should never use
json/xml," then I disagree. JSON is a great way to store and move data,
especially on the web.

To summarize the security part for those new to it: Any time user-submitted
data passes to you, you need to clean it. Otherwise it might include nasty
code that injects itself in your database, in your code, in visitor's
webpages that view it, steals cookies and pretends to be someone else, runs
an fake-clicking service, etc. If you can't ensure you can properly clean
it, for example because arbitrary HTML or Javascript is the intended input
you're gathering, then you need to sandbox it whenever it's presented, like
jsfiddle.net does.

Re: [CODE4LIB] Accordion menus & mobile web best practices

[Chris Moschini]

Hey all,

I work in UX for a little company (Brass Nine Design) and joined the group
to chime in on this UX discussion:

Our library website is currently being redesigned to be responsive.
> The work is being done by an outside design firm and the project is
> being managed by University Relations, our school's PR department. The
> mobile version of our responsive site has several accordion menus


"Unfortunately, no, as this isn’t best practice. Accordions should
> require a click each to open and close; in other words, nothing on your
> page should move without a user action. This is true throughout our sites.
> See the universal Quick Links in mobile."


This is confusing because it's bad advice portrayed as "best practices."
Let's deconstruct it:

*Self-Closing Accordions*
At the most basic, a "self-closing" accordion is just a standard accordion.
Many UI frameworks will actually offer 2 rendering modes for tabs, one
where it's presented as tabs along the top or sides and the relevant pane
for a tab is displayed, another where it's rendered as a vertical or
horizontal accordion. In both of these constructs the other panes are
"self-closing." Forbidding that UI would mean forbidding tabs, which would
be especially strange given many sites' top navs are essentially a tabbed
interface.

So, forbidding the self-closing accordion is bad policy.

*Responsive Design in General*
It's also likely that whoever provided that advice is not thinking
Responsive. If you have your site built for 2 things, "mobile" and "not
mobile," you're not building a Responsive site. A Responsive site is one
that can handle:

   - Today's devices - desktops, laptops, touch-laptops, tablets,
   smartphones, and watches.
   - Tomorrow's devices - likely smaller displays and larger displays,
   higher DPI displays, and blind UI / voice-only.

The "tomorrow's devices" obviously requires a bit of forecasting but there
are things we know are coming, like the above higher DPI and need for
blind/driver's interfaces. Even today, users of the Apple Watch are going
to be happier talking through your site's resources than flipping through
it staring down at the little display on their wrist.

This leads to some technical requirements:

   - No device should be assumed to be touch, mouse, or mouse-only. For
   example many designers will add "Quick Links" to mobile figuring mobile is
   touch and desktop/laptop is mouse. On mobile plodding fingers need to get
   around the site more easily than a smaller, fiddly nav - but what about
   Surface Pro users holding a high-DPI touch tablet, looking at the
   desktop-render of your site - how are they going to deal with your fiddly
   nav? You need to design and build it to interact well with both at all
   sizes.
   - No screen size can really be assumed, although there are a couple of
   industry-standard minimums being established: Devices smaller than 640
   physical pixels in width aren't in today's device mix, and smaller than 280
   "virtual pixels" aren't either. "Virtual pixels" is the width Bootstrap
   sees on a screen, the number of pixels available to font rendering if the
   screen dpi were the historical standard of 72dpi. Usually the real dpi is
   much higher - for example Apple's Retina phones will render at 96dpi,
   144dpi, even 200dpi.
   - Designers can't design for and devs build for a few discrete sizes,
   like "desktop 1280" and "iPhone 320." The site needs to work at every
   single pixel step from 280 on to infinity, or for now, 3200.
   - The usual mechanics of building sites - don't use Flash, replace PDF
   with HTML, deal with browser bugs in today's top devices.
   - If you are going to be kind to blind users and build forward for
   voice-only or voice-primary users like those driving, exercising or
   interacting with a watch or Alexa or some future wearable, you should
   follow Accessibility guidelines, and ARIA.

Accessibility guidelines are pretty old as the web goes and include placing
alt text on some images - any images that contain important information a
blind user would miss out on. And, avoid using CSS and JS tricks that would
hide important text from a screen reader. Following these also happens to
help your SEO score a little bit. Since the original question was about a
University site I should also warn that not doing this may be illegal, as there
are laws  in the US about government
and institutional websites and accessibility to the blind. The laws are
largely toothless as I've never heard of a web designer being cuffed and
lead away in shame (IN SHAME!) for designing an inaccessible site, but if
the conflict is budget vs blind users you might be able to use the law as a
cudgel in a conversation with management to get a win in for the blind.

ARIA is basically what someone earlier in this thread was wondering about -
how would a Screen Reader know a certain section of an accordion was open
or closed? The answer