Muddiest Point: Week 8 (10/31/14)

So, this week's lecture was a lot, I feel like.  Lots of slides, a lot of concepts, and a lot of fine-toothed work in Lab.  I wish we would have had a better explanation of and more experience with FileZilla.

I am also struggling with the concept of absolute vs relative linking.  Is that why, in FileZilla, the remote window, pubic file, there is a file that's titled ".."?  So it makes it easier to build linkable web pages for the My 2600 project?  I would like a little more clarification on it.

As always, thanks!

Week 9 Reading: Get Hexadecimal

Mary is trying to understand!

As with the previous week's "readings", I had a lot of fun playing around with W3C's tutorials and extremely helpful examples. The Cascading style sheet is a more efficient way of formatting the visual elements in an HTML document than using HTML itself to dictate the style. The value of the cascading style sheet is that the properties you manipulate are "inherited" throughout the document, so making a single change to the CSS changes everything controlled by the element you changed. Saves a lot of time if, for instance, the company you were working for rebranded itself and wants blue to be the dominant color instead of, say, green. The designer only has to make the necessary adjustments on the style sheet and the adjustment cascades throughout the elements controlled by the original code. There are pre-formatted CSS's out there, but I understand that it's important to know how to write it (and HTML, of course) by hand. It gives me more power over the design of web-based elements I will (hopefully!) be designing as I move back into the workforce.

A piece of CSS that describes a change in style (a "rule') can be split into several different parts. The selector defines which element of a document will be modified; this can be a header, a paragraph, etc. The declaration does that just that: declares what qualities to display in relation to the selector. The declaration has two parts, a property and a value, which point specifically to discrete variables that can affect the appearance of the selector. In other words, I want to change the appearance of my first header (selector), so my declaration would be to change the color (value) of the font (property). These rules are governed by discrete semantics, which makes it seem pretty simple.

But it's not!

Formatting a coherent CSS requires a lot of abstract design before writing the style sheet. You (well, I) have to hold a design in you (my) mind the whole time we're dealing with brackets and curly brackets and hex codes and alignment buffers. I can start to understand what people mean when they call a piece of code "beautiful".

Moving on, though.

The brilliant thing (but conceptually difficult) thing about CSS is that you can design the entire document in one go. That is, using the specified language provided by, say, W3C's cheat sheets, you can create an entire, consistent thematic design of a website without having to go in and manually change each and every element by hand. If you want your first three headings to be bright pink and in 36 pt Comic Sans, you can specify that in the CSS by simply listing h1 h2 and h3 as the selectors in your rule. No one but no one likes Comic Sans, though, so I don't advise it. Alternately, you can control the design elements of individual headers as their own selectors, and can nest commands like HTML. This is where I see it becoming really difficult to track changes across a long, plain text document.

So, you've manipulated your selectors, declarations, values, and properties into a document that you're rather proud of. What next? You can stick your CSS right into the head of the HTML document and upload it to a browser. Apparently, however, some, but not all, browsers won't know how to read the kind of CSS you've used, and so it's important to tell the browser which language you're using. If some jerk browser is giving your CSS trouble, however, apparently you can insert the rules into HTML's "comment" command.

Also, I've gone and hit "Preview", and it turns out that all this CSS I've been trying to do hasn't affected the blog post. I tried to do the "Inspect Element" option, but while I can change the text color, it doesn't seem to stick. Can you see what I was trying to do here? I put some CSS into the HTML head, but I suppose the Blogger code trumps mine. After much tinkering around and swearing under my breath, it worked when I plugged it into the W3C "Try It!" window, which was comforting. I wanted a pinkish background with lovely yellow letters in the headers. All I got was centered headers. Better than nothing, I suppose. I can see how designing with CSS, combined with proper HTML, can be simultaneously satisfying and infuriating.

Muddiest Point, 10/21/14 (week 7 again, apparently)

I hae a question about Koha.  It's open source, right?  Do I have to be a part of an institution to use it to create a catalogue? 

I've always wanted to create a catalogue for my personal collection, and am not quite savvy enough with Excel.

Or would it be smarter to use Access?

Week 8 Reading and Fun Times: Did you know you can't put HTML in a post's title?

I found that out because I wanted the title to be <Week 8 Reading> </Week 8 Reading>.  Oh, well.

The World Wide Web Consortium (W3C) is a regulating body that oversees more digital standards than I knew even existed.  Indeed, it is they at the W3C who are the overlords of HTML, which I did not know had such a master.  Hyper Text Mark-up Language is a set of tags that communicate the formatting of web sites.  It is, it turns out, a rather simple, concrete set of semantic commands set within brackets that describe a conceptual layout of visual web material.  All HTML, or Extensible HTML (XHTML), documents are satisfyingly balanced with opening and (for the most part) closing tags.  Additional information about the look and design of a website (CSS), as well as metadata information that can grab the attention of search engines (<meta>tags) may be embedded within an HTML document.  The great thing about HTML is that it's simple but flexible.  In addition, in conjunction with the mark-up language, the use of a cascading style sheet means that changes can be made across a whole website (say you wanted to change your site's font, or background color, or height of a logo) just by making a single change in the CSS.  In addition to text and style elements, HTML can be designed to display data in a variety of ways with the <table> tag.  HTML documents can also be designed to be more interactive that just turning a link purple by clicking on it.  Commands such as action and input can enable a site to collect user-submitted information. 

HTML is a wide-spread and useful mark-up language.  But why, you ask, should a would-be librarian even care about this?  The answer, of course, is because web sites matter, and understanding and working with dynamic digital content is integral to an information professional's work. Duh. Why did you even ask that question.  Developing these basic web design skills, and I am aware that these are very basic HTML skills, like the finger painting of HTML, provides the librarian with a certain level of autonomy in creating and managing online content.  However, as the librarians at Georgia State found out, variable skill level between staff members can result in an inconsistent and incomprehensible mess.  Enter Content Management Systems (CMS)!  SpringShare and the like provide slick, coherent templates that are easily tailored to fit a wide variety of needs such as course guides, library instruction support, or database navigation; these guides can then be shared and altered, as fits with the collaborative nature of 21st century information behavior.  I've developed a couple of course and subject guides using the SpringShare CMS, and I can't quite imagine getting the same (beautiful! amazing! useful!) results with my piddling HTML skillset.

The problem with SpringShare is that it's a commercial enterprise, and so it is out of reach for libraries with limited budgets.  The solution ought to be an open source option, such as Drupal or Al Fresco, but there is little material specifically designed for libraries.  Or, as GSU did, simply train your information techs, programmers, and librarians to be the baddest CMS designers around; this is probably the smartest bet to get that all-powerful ROI.  The tables for their CMS, and the description of how the Active Server Page system pulls information out of it, were intimidating, but not incomprehensible.

(But it won't take you anywhere) (But it's still a button I made!)

The W3C HTML Tutorial is a lot of fun. Because we can format in HTML in Blogger, here is something that I wrote in HTML.

Mary Is Great!

Here is a link to a picture of a pine marten. Or, if you don't want to click the link, here is the picture itself:

.

Aren't they adorable but just a little scary?  Just like HTML.

Muddiest Point for Week 7

My Muddiest Point is actually about Muddy Points in general.

Was one due last Friday (the week we had class)?  I bet it was.  And I missed it.  Shoot.

Also: Peer-to-peer networks.  I'm not sure I understand those very well.  P2P connect computers to one another, but not to any regulating mechanism?  Is this how the "dark web" and Tor operate?

Week 7 Reading: NAPS are Great, Google is Greater, and Get Your Act Together, ILS

We all know that the internet is a series of magical voodoo tubes manipulated by powerful eWizards that live in our wireless routers, right?  Well, no (but that would be totally cool).  The truth is simultaneously more mundane and complex than that.  The internet itself is an interconnected series of smaller networks (though highly intelligent computer engineers, the people who name these things are no poets).  If we zoom into the "smallest" network, we see our old friend the LAN linking machines together within a small radius.  The LAN then connects to a larger network at the Point of Presence (POP!) that covers a larger area or multiple LANS (right? I think so. Is this right?), which then feeds into the greater Network Access Point (NAP), which connects to others of its kind worldwide, thus enabling connection between every computer anywhere to every other computer anywhere (that has network capabilities).

With all these machines sending data along these complex layers of networks, something must act as a traffic light to control the flow of information.  This is the job of the router.  Thanks, little guys.  Once a router gives the go-ahead for information to be sent along its path, this global (and sometimes low-orbit) network then requires vast amounts of physical cable (fiber optics-a series of cables, not a series of tubes) to get the data where its going; companies that own these "backbone" cables all work together to maintain the fiber optic system, as mutual destruction is certainly assured if part of the system doesn't work.  So, our data, having been released properly by a friendly neighborhood router, has left its little LAN home and is travelling along the fiber optic spine that stretches across the whole world.   But it gets a little more complex.

The internet, though seemingly a wild splatter of information smeared across the globe, is actually organized according to Internet Protocol (IP).  Every computer connected to the internet has an IP address, a series of eight pairs of numbers (octets) that uniquely identify a location of origin...at least until we surpass 4.3 billion computers, and then I guess we'll figure something else out.  Since IP addresses are meant to be read by a machine, they look a little strange to human eyes, so we assign text to each IP address, which is known as the Domain Name System (DNS), and is familiar to us as, for instance, www.pitt.edu.  Note that there are three components to that address: "www" "pitt" and "edu", the whole thing being known as the Uniform Resource Locator (URL).  These are built in redundancies that allow different servers to search for the location; if, say, "pitt" can't be located (good old 404!), through it's doman name (.edu), it might be located by either of its other components.

We owe a lot to servers, the physical machines on which much of the information on the internet is stored, and which provides us (clients) with access to the material we're looking for (www.pitt.edu).  They have a static IP address; the networks know exactly where they are at all times.  "My" IP changes as I connect to the internet through different wifi networks.  My machine doesn't have an IP address, therefore, but the location of the modem does.

Meanwhile, the above-mentioned complexity of connections results in a user experience that is delightfully easy to use.  Information can be linked together like never before, and libraries are therefore having to deal with the increased expectation for user ease.  Our largely proprietary integrated systems did not anticipate this change in the nature of information consumption, and are scrambling to readjust and remain relevant.  This has involved smashing other services next to existing services without having them integrate their work flows.  For instance, in my experience with the III product Millennium, searching the circulation catalogue for an eBook would not produce any results.  Instead, we'd have to go into a separate OverDrive OPAC designed specifically to search our electronic resource collection.  This was clunky and confusing to patrons who then did not use it, thus keeping circulation of our investment in electronic material low.  Not cost effective, and offensive to the ROI gods.

What we did, therefore, was switch to III's new open source software, Sierra, which has electronic material integrated into both its staff workflows and its sleek, redesigned OPAC.  This was an expensive move to be sure, but the ease of use, expanded search capabilities (narrow results down to material type, for instance, or subject heading, or year published, author, etc), and clean visual design is much more attentive to modern user expectations; it allows greater search flexibility and user satisfaction.  I think the hand-wringing in the "Dismantling the ILS" is uncalled for, actually.  Or, perhaps, the Carnegie Library of Pittsburgh should stand as a positive model of rebuilding an ILS.

I denounce the hand wringing because instead of staring at our own navels as we get washed out on a tide of change, we should be looking ahead to the horizon (nice little nautical metaphor there) where Google is.  Their mission to help develop a healthy, education user base by delivering information for free to users sounds awfully familiar, doesn't it?  Except they seem to be taking our customers.  Excuse me, patrons.  Perhaps we need to look at their business model, which, first of all, fosters and informal and collaborative culture of highly trained staff.  Many of their successful applications (Gmail, Docs, Blogger, Maps, etc) were developed by allowing their engineers pursue projects that interested them.  There are also a fabulous list of failed Google applications (Google Answers-which was mentioned in the video HA!, Buzz, Notebook, etc).  That allowance for failure is refreshing.

Sometimes I get the feeling that librarians are possessive of the knowledge we purport to keep safe, and that can develop into an elitist attitude that may stifle innovation when we need it most.  That doesn't mean I want advertisements in libraries (although that'd be an interesting method of sustainable funding), but I do want us to be more amenable to the Google way of doing things.  Adventurous and world-dominating!  Gone are the days of austere buns and shushing in the stacks!  The idea that a library can organize its information in isolation have gone the way of the card catalogue.  We're not special anymore, Google's made sure of it; we're just the awesome, most amazing specialists.  We need to weigh anchor, we need to continue our ocean metaphor, and catch up if we can.

Week 5 Muddiest Point (09/30/14)

I'm not sure I understand the concept of metadata "schema".  Is it equivalent to MARC codes?  I understand that there is no consistency or standard, but I don't quite understand what...it is.  Is it semantic?  Or is there a semantic way to connect disconnected schemata?  I'm not sure those questions even make sense, as I don't quite understand the concept of "schema".

Thanks!

Week 6 Reading: A Series of Tubes

I want to look at an amusing cat picture on the internet.  This is an easy thing for me to do.  However, there is a lot of work going on behind the scenes that enable me to do this.

Beginning with the military in the '50's, scientists and engineers have built a connected series of data networks that provide us with pictures of cats, among other, less-important things like email, online scholarly journals, Yelp! reviews, interactive maps, etc.  There are many different kinds of computer networks, the most famous being the Internet (maybe you have heard of it, I don't know). These days, data is sent from a source to an end-user through packaging the information with source and destination information.  These packets of data can travel through physical and virtual topographies in order to reach their destination.

The physical structures of computer networks include different kinds of cables (twisted pair for telecommunications, coaxial cable for TVs, optical fiber for lots of cat pictures travelling under the ocean, etc); wireless technologies send data through earth-bound terrestrial microwaves (this week's Term of the Week) or up into space via satellites, the ubiquitous cell phone towers blinking in the night, and radio frequencies.

Once the cat picture has raced across a physical structure, it encounters a node, which is a kind of door into the destination.  These doors have specific addresses (NIC) and codes (MAC) that allow the cat picture to locate the correct destination and obtain access; once it finds the right place, the data gets "scrubbed" by a repeater.  Sending the cat picture from one network, say a WAN, to another (LAN, or HAN?  Maybe?  This is conceptually difficult for me, I admit) requires that these networks communicate with one another; routers and modems regulate this process, and firewalls protect it.

The digital structure of computer networks is different than the physical topology.  Network designs vary in how many connections there are between participating nodes; the more connections, the better, but more connections means a higher cost.  On top of this, virtual networks can be built on top of existing networks.

The links between these networks are governed by communications protocols such as the Ethernet family, which results in the inability to mooch your neighbor's wifi because it requires a "wireless access key"; Internet Protocol Suite, which the Wikipedia article calls "the foundation of all modern network", and manages to govern information exchanges over an unreliable network; SONET/SDH; and Asynchronous Transfer Mode, which is still relevant for connecting an ISP to someone in their home, trying to find a good cat picture.

The size and scope of networks vary.  They can be only within businesses/between business and their clients (intranets and extranets), small enough to fit into your house (PANs that govern wireless printers to print cat picture); city-wide (MAN!  I would love to see Pittsburgh have one of these); worldwide, so that your mobile carrier can drop your call (GAN), and, of course the Local Area Network, or LAN.  LAN is the type of network most Average Joes like me use most frequently.  It evolved out of a rapidly increasing use of connected computers in close geographic range (the office, the lab, the educational department, etc), and resulted in a standardization of protocols.  

Security issues abound when discussing interconnected computer networks, of course.  There is the issue of network security, that (hopefully) prevents unauthorized entities from accessing, modifying, stealing, and otherwise manipulating information.   If you've been living under a rock, the issue of network surveillance is very important in this new, interconnected age.  Powerful organizations (governments, law enforcement bodies, the Mafia, etc) monitor the data being exchanged over various networks.  For safety or nefarious purposes?  The debate is wide-spread, heated, and far from over.

Moving on to RFID, and its potential for use in libraries.

Replacing barcodes with RFID chips could speed up library work considerably.  I've dragged a squeaking cart loaded down with a laser scanner clumsily connected to an aging laptop through stack after stack to preform inventory.  This cumbersome and time-consuming task could optimized with an RFID scanner.  Circulation could be optimized by RFID scanners in book drops (some patrons already think this happens, that a book gets checked in immediately after they put it in the drop), checking in/out large stacks of items at once, and having security information encoded onto and RFID for more efficient loss prevention.  Self-check out is already in place in many libraries, but it still relies on barcode scanning and (generally) magnetic security screening; trying to teach patrons to "thump" a book after they've checked it out has, in  my experience, been a difficult task that leads to library staff (Mary) having to stop them at the door because they've set off the alarms anyway.  Streamlining self-checkout might encourage more use, and finally start paying off the exorbitant price of the self-checkout machines.  This, however, would make the circulation clerks very lonely.

RFID technology permeates more and more of our world.  It is currently more expensive than printing barcodes, but it may be inevitable that libraries will have to move to RFIDs simply because it is the available technology.  This presents some problems.  The chips are relatively easy to remove or veil, which increases the potential of loss.  Smaller items (magazines, thin books, children's books) present challenges for reading individual tags.  Replacing tags can become costly in a way that slapping another barcode on an item never will.

Anyway, in case you were wondering: