In which I talk to myself a lot

More on setting up my first Drupal/Git/Drush site...

I've opted to ignore the multitudinous potential php settings for now, and am hoping things just work for the moment. Otherwise I'll keep procrastinating by fussing with server settings forever. I did find that my php version is easily changed by clicking edit on a domain in the dreamhost panel. And then my Drupal install moseys along much better.

If someone wanted to drop me a lecture/note about how I shouldn't be toying with D8 on a live server because [security] I'd actually be curious to know more.

Oh here we are, the php.ini wiki page for dreamhost: "We seriously aren't kidding about this" edition. Okay, yeah, still going to try not to mess with it for now. SO, moving along. Complete install using appropriate database. tum tetum.

Got hostname right, port default appears ok. Dreamhost phpmyadmin seems to have organized my dbs using the underscore I dropped in to differentiate test and production dbs. Hoping that's not a problem. Totally writing things to db now! whee. This is so nerve wracking, given how frequently things seem to break. Then I'll have to go back and clone to my root directory for my site, too, but not until I have something worth having up front.

meh, nuts. Admin menu doesn't display, just shows "array." Works fine on local. Maybe I'm not doing this quite right if things are that different. Also the whole thing is slow as all get out. oh, I needed to clear my cache. When did drush cc all go the way of the dodo? It's hard to keep up with a learning curve that keeps doing loop-the-loops.

ehhh I got distracted working frontend site building and haven't been keeping notes! I still can't get my search block to display, not sure why. Finally got my blog view to display the grid first by disabling the contextual filter (tho I'm still not sure why it was showing "3 2014" instead of "May 2014").

Now need to get my drush site aliases up and working so I can push the db up and see what happens. I suppose I might as well be doing my dev on my /test directory, since I'm not really doing dev so much as design. Heaven help me if I ever get to the theming part of the program here. At least my concept is super simple and minimalist. For now. Now where did I put my sketches?

Or I could just export the dang db and import it to the remote and deal with it later when I have slightly more time. It bothers me to do this the "wrong" way, though. Ok, export, import check. Then I just need to... definitely not the most elegant way to do this. Kinda broke things. Totally lost track of my git system. Maybe I should just get my site-aliases to work.

Note to self: fix things with chmod u+w. Finally got back to close to where I started by copying settings.php over. Somewhat easier to follow instructions for site aliases here. That plus the instructions in example.aliases.drushrc.php. 

Dreamhost specific Drush install instructions!? yes! ... no. That installs the old Drush, I need Drush 7, which requires composer, which requires that the php phar extension be enabled, which it isn't. Seriously, you've got to be kidding me. I just want to sync my database! Ok, got the phar extension working, though I *really* don't understand why it wasn't. See also (again) Dreamhost's wiki here on php settings.

Finally got Drush on the remote, more or less. So now running drush @test status locally at least comes up with a different result... "Drush 7.0-dev does not support Drupal" and "Fatal error: Call to undefined function conf_path() in /home/[me]/.composer/vendor/drush/drush/includes/bootstrap.inc on line 783" ...what? ok, maybe I need to do my alias a little different, can't get that until I run the install script again on the remote? Do I even remember how to do this part anymore?? ok, got drush site-alias @self copied, added to my drushrc.php locally, eventually got rid of a stray paren that was really messing things up, and finally drush @test status works!

... now I can try syncing my dbs. Which fails on the first try with "Error: no database record could be found for source @dev." erm. Ok, so both @dev and @test pass drush sql-conf. That's good. ...I'm completely at my wits end here. HELP.

And then I can set up an alias for my production site, which I haven't even provisioned or whatever yet- need to clone to site root, install, set up alias, and sync. Right? That should be easy at this point. ...right?

Eventually I will get to theming!

Overloaded - Journaling some progress

his will be a less coherent post than usual, just because I'm in process a lot sooner than I thought I'd be. Going back to my Grand List, the intent was that I would research several different CMS platforms (Drupal, WordPress, Joomla etc) before choosing one, or even deciding that a full fledged CMS was too heavy for my purposes. In an ideal world (I've been using "ideal" more lately. hm. Self-awareness?), I'd probably design my own database and create the whole thing from scratch. Since that would require being a db architect, it would take quite a lot longer than winging it in a CMS.

More recently, I had decided to go with WordPress, simply because I have some experience with it already and would be building on that, rather than learning yet another new skill set. I had been thinking that Drupal was the more sophisticated option, and that I could learn yet more awesome new things by installing it, but second-guessed myself into a corner. Really, WordPress has given me some pretty big headaches over the last couple of years.

This past weekend was the National Day of Civic Hacking. Within a span of four days, my whole outlook and project list merged onto a gigantic, fast-moving highway of projects, people, inspiration and busy, busy schedules. Now I find myself wrapped up in Code for DC, a project to map migration and DC school boundaries, hopefully getting further involved with Girl Develop It, and throwing myself at Drupal Core.

The big problem here is that every single thing I just listed has not just a physical group and projects, but Hackpads, Trello boards, Google Groups, Meetups, Twitter accounts, GitHub accounts, CKAN site, IRC channels, calendars, forums, websites and good lord do I have a lot of tabs open. I think I linked up with everyone from the weekend, signed up for everything I needed to... at this point I'm just hoping that anything important will ping a notification to my email, otherwise it'll be lost in the aether.

But back to Drupal. Let's just take a look at where I'm at, mostly for personal reference. I signed onto Drupal.org, and to DrupalMentoring.org. Joined the DC Drupalers meetup. Have [just] four IRC channels up in preparation for the Office Hours later tonight from the mentoring people (who I hope will be able to give me dummy points on installation and patches and link me up with an appropriately straightforward project [open issue]).

Some questions, having just read the Drupal overview here (front-end installation stuff) and nearly every other page I could find after that:

• Why XHTML?
• What exactly happens in terms of nodes, paths, blocks, users when a page is requested? How does the request play out?
• Wait, so bootstrap, which isn't bootstrapping, or Bootstrap? argh. But sort of like the WordPress Loop, yes?
• I've really got to learn PHP/more PHP. What are alternatives to PHP? How else can web pages be dynamic?
• So there are issues listed on Drupal.org and DrupalMentoring.org... how are they related? Same thing, different interface? (oh, I see, they're linked and the Drupal.org is the main page for info comments etc)

... a bit brain-dead right now, which is unhelpful given that the mentoring office hours are in... an hour!

Web Design Process: Yet More Lists

ll right, first things first. Before I go trying to put my website together willy nilly, I need a plan, a master list of desired components and functionality, and a general idea of how to get from here to there. Disclaimer: I have not actually done this before! I've worked on sites designed by someone else, I've done some super basic HTML/CSS work (like my pesky resume and my placeholder website), and I've certainly spent plenty of time thinking about it and reading and researching. So here goes:

Things I'd like from my site:

• A Gallery of photos: no commenting, prints for sale, easily populated (Lightroom export?), cataloged by keyword, location, highly searchable, and someday I'd like it to include interactive collaging
• About/info page: bio 
• Contact: email, links to me elsewhere like twitter etc, RSS for photos and blog?
• Blog: old posts from blogger + new posts, shiny layout, browseable, comments, share buttons
• Portfolio: other design work, samples, articles, projects, certificates, whatever else
• Someday: a sandbox area near the portfolio for projects in progress, something to do with Github? 
• Aesthetic: simple, lots of white space (or black space), nice OFL (Open Font License) fonts and thin lines, simple image display, good navigation, one animation/movement/interactive element on top page. 

The basic steps outlined below are a combination of my notes from several sources. I learned most of the prototyping and user-testing steps from a class called Human Computer Interaction taught online by Scott Klemmer from Stanford. Not my favorite class on Coursera due to some frustration with the peer-grading setup, but nonetheless informative.

I also discovered that a local web design etc firm called Clikzy Creative posted their entire design process to their site so that clients will know what they're getting into. My process will be a bit different, of course, but it's good to know how a more formal environment would handle the same task.

• Essentially: "Discovery, Site Map, Content, Wireframe, Mockup, Revise, Develop, SEO, Launch."

The Moxie Design Studio also has their process up on their website. They do a bunch of websites for local Alexandria businesses, so I had seen their work quite a few places already. They also list a general set of project prices on their site, which is somewhat unusual, but very helpful since I had no idea what I should be charging for my work.

• So again, an essential process looks like: "Discussion, Goals, Mockups, Revisions, Development and Programming, Soft Launch and Client Training, Full Launch and two weeks included Support." 

It's really hard being independent and not letting clients take advantage of you by asking "just a quick question" that actually takes half an hour and is billable. And that's just one reason I'd rather not work for myself!

Back to my own website. A few basic steps to get there:

1. Define required elements - site map (above)
2. Find appropriate platform
3. Wireframing, prototypes, mockups - grids?
4. Testing it on unsuspecting potential users - feedback and revision
5. Build, develop, whatever you want to call it
6. Design details/ illustrations? Finishing touches
7. Later additions: animation, better databases? E-commerce... 

Each step along the way will probably be a bit more involved, but that should give me a good starting framework to go on. Don't mind me if both my website and blog suddenly disappear while I'm shuffling things around...

Optional HTML, good idea?

ack along the trail I was following in my post on carousels and web design firms I stumbled across Google's HTML and CSS Style Guide. This is, of course, just one resource in a sea of options, and as the name suggests, "more like guidelines, anyway." I found it useful to glance over to get an idea of what to do with my code once I had grasped some of the basic stuff.

The Style Guide has some helpful reminders about indentation (don't mix spaces and tabs, indent child elements), plus general etiquette (stick with the previous author's style, be consistent). The whole thing can be summed up as: optimize as much as possible, made code easy for collaborators to scan through. Somewhere halfway down the page, though, I found a section on optional HTML tags.

In all fairness, both Google and the WhatWG HTML5 spec frame this concept with "you may" and "consider" and other non-mandatory type phrasing. But I thought, hey, here's another way to be kind of minimalist, keep things tidy, not have more clutter than is really needed. And indeed, I could simply be rid of the <html>, <head>, <body> and a whole pile of closing tags. But! the traditionalist and skeptic in me took a pause and said, "Should I really mess with this right now? I haven't noticed this implemented anywhere, and my classes/research have all indicated that closing tags are the basis of a well-formed markup language. Maybe this is best left for another day."

Well ok, inner-skeptic, but I still want to learn a little more. So, some questions:

• What exactly constitutes a valid, well-formed markup language?

A markup language (ML just for now, though not to be confused with ML, the functional programming language I just couldn't deal with) is used to annotate and describe a document. I'm not going to go into the history and fascinating variety of MLs here, so suffice to say that in this case, for HTML or XML, the markup is intended to indicate what each tagged element contains. In HTML this could be a <header> or a <section>, which provide the browser with standard elements to display and style accordingly. XML uses tags to describe content, too, but is best suited to databases (DB). Since it is used in DBs, it is particularly necessary to have both starting and ending tags and to completely conform with the DB definition or else any references to each element would just fail. Not going into that here.

So a well-formed and valid bunch of whicheverML follows all the rules in the relevant specification and passes tests like the W3C validator. Well-formed generally refers to syntax, so elements that are arranged according the rules are syntactically correct. The traditional definition of well-formed includes closing anything that has an opening tag and properly nesting elements. A valid ML also follows its Document Type Definition (DTD), a sort of grammar dictionary for how to apply the language (here's the HTML4 DTD, for example). See the W3C validator's info here.

• How much of a difference in speed does tag omission really confer? 

There's not a ton of this out there on the surface, but again, Google has been implementing, or rather, omitting, the optional tags to decrease file size. When every bit counts, taking out even just a few characters here and there can add up to a big difference. According to the Google Developers article and video on reducing HTML document file size, this can actually result in "5-20% savings" in load time.

There's a conversation on StackOverflow from 2010 about how much of a difference this could actually make. It's hypothesized that especially at Google's size, "</body></html> is 14 characters and at 3 billion searches per day, it amounts to approximately39.12 GB of data per day ignoring compressions, or around 26 GB if we take gzipping into account." And another discussion from about the same time that goes more in depth on the whole issue. 

• Are there any arguments against tag omission on the whole?

Some people argue for tag omission for readability, others argue against tag omission for readability. So either way, people will eventually stumble through your code. The best reason not to omit is probably compatibility. Some browsers might not recognize an unclosed element properly, some scripts may get confused, it really depends what the content is expected to do. It winds up being a personal choice: you can include the superfluous, or you can be hyper meticulous and make sure you are only omitting tags that can be omitted and not getting confused in the process.

• Is this just one of those crazy, Google-is-way-ahead-of-everyone-else-again things?

Hard to say. Tag omission is out there, but most people don't need the speed that badly. The implementation status on the HTML5 spec only suggests that tag omission hasn't been tested on the latest browser builds.

Moving on, letting go

he hardest part of a project for me is deciding that it's finished. Usually it takes getting distracted by something new for me to really move on (this probably goes for some other stuff, too...) because otherwise I just can't let myself stop futzing, adjusting and perfecting. Translation: beating my head against something that just isn't making any more progress. So I have to learn to let it go, move forward.

In case you haven't been following along, in this case I'm referring to my "One Week Website" series of posts (clearly the timing didn't quite work out, but I never really expected it to). I started designing a new resume, and made great leaps of progress... until I ran into a wall attempting to make it perfectly responsive. This actually would have worked fine except that in keeping it super simple I was avoiding @media queries and pretty much everything except some basic CSS (see below).

And it was all going pretty well until I went to make a PDF. I have no idea how print formatting works, from web page to print dialog to PDF, but the margins didn't behave properly, it didn't fit on one page, and the white space looked weird instead of stylish (at least I hope the HTML version looks decent). So I reformatted a bit with those 800px min-widths on the #page-wrap and #content sections. Of course, now the #web and #general skills lists don't float and switch from side-by-side layout to being a single column, which means the 50% layout looks darn silly on mobile.

I tried using sections and header and h1-h6 instead of a flock of divs, and since this is a one use document, I just went with ids rather than classes. Feels wrong, though. At the very least, I have a resume that looks a little better than an old Word document, even if it isn't actually responsive. And! I did finally stop poking at it and just hit print.

body {font: normal 1em Times, serif;}
#page-wrap {width: 75%; margin: 5% auto; min-width: 800px;}
#me {display: inline-block; width: 100%; position: relative;}
#logoname {float: left; width: 25%; min-width: 165px;}
#logoname span span:first-of-type {color: #6C8771;}
#logoname span {color: #4D4D4D}
#contact {text-align: right; position: absolute; right: 0; bottom: 0;}
#content {width: 75%; float: right; min-width: 800px;}
#skills li {text-indent: -0.5em; padding-left: .5em;}
#web {float: left; width: 50%; clear: both;}
#general {float: left; width: 50%;}
#experience {clear: both;}
#learning li {display: inline; padding: 0 0.5em; border-left: 1px solid black;}
#learning li:last-child {border-right: 1px solid black;}

section {border-top: 1px solid black; padding-bottom: 20px;}
h1, h2, h3, h4, h5 {font-family: Baskerville, Palantino, serif; border-top: 1px solid black; margin: 0; padding: 0; display: inline-block; margin-bottom: 2%;}
h1 {font-size: 2em;}
h4 {float: left; font-size: 1.17em;}
h5 {padding-top: 3px;}
a {text-decoration: none; color: black;}
a:hover {color: gray;}
ul {list-style: none; padding:0; margin: 0;}
li {margin-bottom: 1%;}
dl {padding: 0; margin: 0;}
dt {padding-bottom: 1px;}
dd {padding-bottom: 1%;}

Now I just need to figure out if I really want to make my entire resume public on the internet. My feeling is no, not one bit, but then part of the point of doing it in HTML is lost. Still, it was fun to put together, and that's more important anyway.

Resumes and RWD: Content, content, content

ho knew I was doing it all wrong? Throughout my working life, my resume has been horrendously unattractive, difficult to scan, uninteresting, bland, and generally makes me wonder how I've gotten as many interviews as I have. Well, no more! I recently stumbled across a couple of graphic designers' resumes and realized that a resume doesn't have to be a dry, formulaic monstrosity (mine was also much too long, a sure indicator of my lack of experience). In my own defense, I had put that resume together while working and looking at jobs in the federal government, which is really not known for being terribly stylish. But that's just an excuse.

In reading back over some previous versions of my resume (pre-Git infestation in my life, so piles of old files), I noticed that not only had I dropped some minor positions from the tail-end, but I had also lost interesting tidbits like the list of gallery shows my artwork had been displayed in. I'm not currently looking for work as a photographer, but those shows were something I was proud of and had worked hard on. Could they be considered work experience, or just an example of well-roundedness? Is character an asset better addressed in a cover-letter and/or interview?

Somewhere not too long ago I made a mental note that it was possible to write a resume in HTML, rather than the old word processor approach. Then my brain did its thing and a dim little bulb lit up; an HTML resume is a great way to show off the fact that I can create a bit of content and do some basic styling. Plus, it would get me away from the headache of nudging paragraphs and headings around in Google Drive. Complete control! mwaha– ...I've been saying that too much in these posts lately. oops.

Here's where I went slightly astray: doing a bit of background research on HTML resumes. I only meant to find a couple examples (see my collection here), but somewhere along the way ran into A List Apart (ALA)'s article on responsive resumes. Which is when I realized I had seen a retweet of this article on responsive web design (RWD) earlier in the day. Which took me back to another article from ALA on fluid layouts, flexible images, and media queries (RWD in a nutshell), further explained with handy percentage-based grid templates and some guidance on element sizing for those of us who just don't grok maths.

Somewhere in there, the best explanation for the whole business of RWD was from Mark Boulton. Instead of designing for a computer screen, an iphone, or even a printed page, designers should think in the opposite direction: from the content outwards. Start with the content, lay it out in relative terms (ems and %s), think of the whole as a fluid form originating from a single element. Design outwards from the logo, from a critical ad for your store, from a dynamically generated element like a blog post. Like all logical things, this makes perfect sense once you've heard it.

"Start designing from the content out" also makes sense in the context of "content first, then style." You can't style something that doesn't exist, and it's much more difficult to stuff your content into arbitrarily created elements. So step one is to create or define your content, step two is to style it in relative terms. A resume is also a prime place to avoid contentless content and to make sure that you are getting the right information to the user (your future employer). So to review, the most important things in design are content, content, content.

Whew, well that was sort of step one in the process. Coming up next should be editing the old resume into a more manageable sound bite, then designing a new layout before looking too closely at inspiration. That way I can get raw me onto the page before introducing outside forces.

OWW: Tidying up

o, how about that acronym? It is sort of descriptive of how my brain gets to feeling after too many hours staring at the screen. Here's a post on some trouble-shooting of the last two posts, and tidying up any loose ends that I can.

First, the original list post was confused about what element tags to use for embedding HTML content. I started with embed because it sounded like what I wanted to do, but it's actually "for an external (typically non-HTML) application or interactive content." Then I found object, which "will either be treated as an image, as a nested browsing context, or as an external resource to be processed by a plugin." And finally iframe which I had really thought went the way of the dodo for some reason, and which "represents a nested browsing context." Sooo...

Second, hopefully related, the embedded HTML doesn't show up in Google Reader. By switching to object tags, I did get it to at least display alt text. Turns out this is indeed a security problem with RSS feeds.

However, problem B is that the entire embed shows up as an empty frame for at least one reader using (you guessed it) Internet Explorer (IE. Abbreviations will carry into future posts). I suspect this has something to do with cross-site restrictions/same origin policies, or possibly just content blocking. Looked up user agent switching and (yay) Chrome has a built in feature to switch user agents from the developer console. However, everything displayed just fine when I checked the blog through the IE emulators, so I dunno.

The original list has now been tidied up, streamlined, and the stray notes I had in there for my own benefit have been relegated to drafted blog posts. I probably shouldn't blow any time styling it, but it's tempting. I would at least like to standardise some nice classy, plain styling for future documentation purposes.

Also, since this entire blog ought to be transferred to my domain in the near future, I'm not sure how much will be lost in the translation, so I'm not futzing about style too much right now. I did settle on using courier bold to highlight code terms, but then discovered that the code element does the same thing, so will use that henceforth.

Oh yes, and I had intended to use some pre and code elements in my TodoList file, but they didn't display properly on the first two tries. Turns out the < and > are still interpreted as HTML, so substituting in "&lt" and "&gt" respectively was necessary. It's worth noting that all of my HTML/CSS coding is happening using only TextWrangler, having upgraded from TextEdit. Someday fancy software (especially for previewing work) would be nice, but right now I like this basic approach.

Phew. I like fixing all the little problems, but it can certainly get a bit tedious. All my librarian research skills sure are coming in handy!

Gitifying the OneWeekWebsiteList

ote to self: document as I go, not after the fact. It felt a lot like I was running in circles trying to find documentation and n00b help as I was working on this, so I didn't take notes along the way. A lot of the point of this first step was to familiarise myself with a few new systems (Git, GitHub, Terminal, Unix command line, Vim), as well as just publishing my strategy for creating a bigger, better website for myself. The entire project is more about learning than having a finished product (although it would be nice to sell a photo again, someday), so each post is intended as a reference for myself, as you'll note from the links peppered throughout the text below.

I apologise in advance, too, for these posts likely being very dry, incoherent and plentiful. I'm often writing from the top of my head and focusing on developing and documenting rather than fine literary prose. Coincidentally, my horoscope for today:

Once you break down a task into manageable chunks, you'll discover that your challenges are not really that hard. You are absolutely capable of meeting the goal you projected at the beginning.

Essential breakdown of Gitification of The List:

• Wrote project todo list.
• Thought about purpose and use of list- dynamic, changing, updating steps as I go to keep track of overall process.
• Translated list into HTML 
• Created GitHub repository (repo) for new project, cloned repo onto local drive
• Updated and committed ReadMe file on GitHub
• Discovered that this threw my local clone out of sync, figured out basics of git pull.
• Finally figured out how to control the vim editor in Terminal (thanks largely to the patient human who helped me with basic commands) to add messages to merges and commits when I forget to use the -m option .
• At this point, the list was basically done, and pushed to GitHub. 
• Researched how to publish a repo to the web so that it looks like an actual page. I had seen a friend do this with a basic design portfolio, but couldn't find a simple button to push in order to see repo files in anything other than raw code. 
• Turns out I had to create an entire new branch in my repo, move everything, and when it still didn't seem to be working, realised I had left off the obvious !DOCTYPE declaration.  Actually, I could have just left it and popped in a reference or something. oh well.
• Had also found this Google Style Guide, which mentioned that some element tags are optional in HTML5. So I guess my dunderheadedness over formatting my initial list file wasn't actually critical, but I haven't implemented the recommendations yet. Also ran it past a W3C validator. 
• Meanwhile, I just need to get the published OneWeekWebsiteList.html into my blogpost, somehow, in a way that would save me from updating said blogpost every time I modified the original file. I found the embed element in the HTML5 spec to be a simple solution. Presumably there's some way I should have done this with PHP or scripting or one of those things I don't know how to do yet.
• So, one properly sized embed element and a div element with simple border later, the list mostly worked as dynamic content. 

Unfortunately, I couldn't discover until after publishing that the embedded HTML file doesn't display in Google Reader. It's visible in the RSS feed itself, so the problem comes somewhere in the aggregator?

I would love to hear about better solutions to this problem, as I just went for the first option I could find in the interest of moving forward. I've also just now switched to an object element, since embed seems to be intended for non-HTML content. Any thoughts?

One Week Website

ow, in all fairness, this was a very optimistic concept on my part. I can put together a decent looking personal website in a week, no problem. Getting through the entire process I've outlined below, blogging and documenting each step, including research, references, background, backend, comparison shopping, self-analysis and content transfer? Not so easy.

The idea, however, in documenting the entire process is that I, and anyone else who cares to poke around, can review my notes and see the progress I've made and the time/effort I put in to doing a relatively thorough job. Thoroughness might actually be a fault of mine. I have a need to understand everything about a topic, to understand how the wheel works before I drive the car, etc. I can't just install WordPress (WP) and go with it, I need to understand how the backend works, how my data and files are structured, how I can query that database, and why that form is the right choice for me.

This means my initial process is slower than would be ideal, but I think the payoff in the long run will be greater. I have learned to let some things slide for the time being, marking them to revisit later when I have enough background to understand them better.

First, I need to figure out how to track this list. Do I want to Gitify (version track) it? repost at the end of each sub-post? certainly link back to the original list with each execution of a list item. It seems like a version-tracked version I can update and reference would be best... without having to republish every time I make a change. So I'll have to embed the list (published github page) itself:

ps. Yes, this looks ghastly. I need to publish and then iterate. I hear this is a thing you do.
pps. I see the embed doesn't work in Google Reader. Will have to figure that out, too.

Frustrated Ramblings

his is not my usual style, and I don't like posting things like this, but I've spent too much of today irked with various Google products. Below is a version of a post I made to a Gmail Google Group. I could go into more detail and try to get across how frustrated I am that Google is making it more and more difficult to do simple things simply, rather than the other way around. I can't even easily find a basic "feedback on our new product" option anymore, which is pretty disappointing.

Google, what happened? Back in 2004 when we all got Gmail for the first time everything was so friendly and thoughtful, and now I get the sinking feeling that users are being left behind in the interest of a shiny new future. Stop pushing so hard.

So here's a couple thoughts on the trial version of the new compose setup for gmail:

1) I've seen way, way too many people saying "whelp, guess I'll get used to it" about this and other gmail/google changes. This seems wrong: the UI should conform to user needs, not the user to the UI. While some people may prefer this new layout, it's not right for everyone. Which brings me to:

2) Not all messages are going to be short little snippets that should be composed in a mini window, tucked over the inbox, or even popped out. Many people compose complex, lengthy emails and require the space both physically on the screen and mentally by having the new message be the only thing visible.

On top of that, hiding all the controls makes it much more difficult to see what's available at a glance, remember to add links or formatting, and as other users have said, to glance at the send list to make sure a recipients work/home email has been selected.

Therefore, perhaps the new compose could be implemented more like the priority inboxes, as a choice that each user can make and switch between based on actual, personal needs.


More from WebMonkey.com, ParisLemon (who wants still less), GHacks (which refers to people like me as "advanced users") and some snarky people over here. You get the idea.

Junk information

There's a lot that's been written lately about how much information is available to us through the internet and out in the world. It seems as though people are overstimulated and yet somehow uninspired, almost stifled by the options available. Calvin's dad once had a fit about the wide variety of peanut butters available in the grocery store. It's kind of like that. 

So there are tweets and Facebook posts at the bottom of it, meaningless snippets, but capable of sucking away half a person's day. One level up are blogs, newspaper articles (online or not) and magazines. While these are slightly more in depth discussions or examinations of a topic, a couple of pages are most often not sufficient for true thoroughness. A really well written article can, however, inspire further investigation on the part of a reader by prodding their curiosity and providing a vivid window into the subject.

Here are some bits and pieces of associated information that I've pulled together here. My favourite is a quotation from a professor Aitken, who I referenced in my thesis on childhood memory a few years ago. Aitken suggests that the best way to understand or memorize something is to love and care about it first and seek meaning in it, giving yourself context and motivation for information retention, as well as a more complex understanding of the subject through muti-layered assimilation. 

"The thing to do is to learn by heart, not because one has to, but because one loves the thing and is interested in it." -Professor Alexander Craig Aitken (Ian M.L. Hunter, “An Exceptional Memory,” In Memory Observed: Remembering in Natural Contexts, ed. Ulric Neisser (New York: Worth Publishers, 2000), 515.) 

And on the subject of tidbits versus comprehensive:

Many of us worry about a decline in deep, reflective, cover-to-cover reading. We deplore the shift to blogs, snippets, and tweets. In the case of research, we might concede that word searches have advantages, but we refuse to believe that they can lead to the kind of understanding that comes with the continuous study of an entire book. Is it true, however, that deep reading has declined, or even that it always prevailed? Studies by Kevin Sharpe, Lisa Jardine, and Anthony Grafton have proven that humanists in the 16th and 17th centuries often read discontinuously, searching for passages that could be used in the cut and thrust of rhetorical battles at court, or for nuggets of wisdom that could be copied into commonplace books and consulted out of context. - Robert Darnton, "Five myths about the 'Information Age" The Chronicle of Higher Education, April 17, 2011.

Lastly, some associated bits on multitasking, technology and focus from NYTimes and elsewhere can be found starting with this here blog post.


Photo from Capitol Hill Books, winter 2011. Not junk information?

Conflict of interest

Not to sound schizophrenic, but I have a choice here, and I'm of two minds about it (and they keep fighting. In my head). On the one hand, I could be making money (in theory) off this blog. I could monetize, I could use the $100 Google AdWords coupon they sent me (and look into AdSense, too), I could sell something, I could even put a Paypal donation button on here.

Or I could do none of those things, appealing in part because then I have to do none of those things (I'm not lazy, I just like to conserve time). I could have a beautiful, ad-free blog, affix this lovely ad-free blog sticker to myself (er, I mean, the blog) and skip about on my moral and ethical high ground.



I don't really want to expect revenue from my readers, or plague them with advertisements, or, in general, be a sellout. As a librarian, the point of blogging (and life) is to share information with people who need it (even if they don't know they need it. mwahaha.) I realise that just putting up a couple ads and such isn't really demanding anything more from readers than the rest of the internet does, but heck, I don't want to be the rest of the internet. I want my motives for writing to be pure and simple (not that this seems to generate frequent updates).

On the other other hand, I'm kinda broke.

The conclusion I've come to is that as soon as I stop procrastinating and set things up, I'll do a trial run of Attempting To Make Money With My Blog. Comments and thoughts on this whole thing would be appreciated. I'm likely over-thinking it. I'm also trying out partial syndication, so people who get my blog in a feed reader will need to click through to get the full post. Again, thoughts appreciated.

EDIT: That was a dumb idea. "Short" syndication publishes a fragment, doesn't append so much as an ellipses, and therefore doesn't let the reader know that there's more to be had just one click away. If I could get a "read more" link in there it would be fine. Heck, I say, to heck with that.

There's a Calvin and Hobbes strip that illustrates how I feel about the internet, which I wont post here because I'm sure it would incur all kinds of copyright wrath. It's the one where Calvin is standing outside staring at the stars and he yells "I'M SIGNIFICANT!" pauses, then says "...screamed the dust speck."

Lessons learned

Commenting and leaving your website/blog info here and there on the interwebs can actually generate traffic. So sayeth my recent interpretation of the data I've been collecting on this very blog. Before you freak out, no, I can't tell exactly who you are, and if you're on the web you're spreading information about your surfing habits all over the place anyway. I left a comment over on Meredith Farkas' blog, Information Wants to be Free after the CIL2010 conference along with my blog address, and got a few clicks off it. That's certainly one way networking works, and why we should form connections online. (There's a building slowly on top of foundations metaphor here somwhere)

Posting links on certain days of the week, and times of day results in different levels of click-interest. I got a ton of clicks yesterday, and I suspect this is because people were le bored at work on a Monday. I'll have to devise a controlled experiment to test this theory. Maybe posting the same number of links of similar type every day? There are also notable changes in click frequency based on how I've "sold" the link in my tweet or text.

People are more likely to respond to a post or a link if they can see that others have done so before them. Facebook posts with lots of comments or clicks get shuffled to the top in the "Top Stories" feed, and if there are several comments saying "omg, so cool" and "this is great!" everyone else will click, too.

Which brings me to the irritating point that people are frequently more interested in visual content than in text. (this post is already screwed) This generally makes it difficult to communicate information to people because they are lazy or unwilling to go through all the trouble of reading. The blog Information is Beautiful takes advantage of this by posting awesome graphs, diagrams, charts and whatnot that are visually interesting, full of information, and make their point. I admit that I am also guilty of this trend. When I go through my Google Reader feed at lunch every day I beeline for the "pretty" items, the webcomics, and posts I know will be brief.

I'll just conclude by saying that posting interesting, wordy content and creating a reader base isn't as easy as one might think.

(if I put a kitten here, would you be more interested? another future study.)

Quizzes! Games! Real Science!

It seems that the BBC (who I still find more trustworthy and comprehensive than the average US news service just because they're foreign) has a website (called Lab UK) dedicated to conducting studies on the internet through quizzes and such. Their big tagline varies along the lines of "Real Science!!" which I find quite amusing. You do what you have to in order to get your readers interested, I guess, but the biologist in me flinches when they say "Real Science!!" They have an information tab for [Real] scientists, which is more illuminating than the FAQ and info pages. Anyway, at the very least it's a more productive way to waste time playing online than the usual quizzes and games, and you still get a cute result at the end. Requires a BBC id/pword, quick registration, ostensibly to protect your answers and results. It's really fairly shrewd of whoever conceptualized Lab UK...

I did the "Web Behaviour Test:"

I am a Web Elk! (gr)

Slow-moving - Web Elks like you take their time finding exactly the right morsels of information – just like the real-world elk who carefully browses for shoots and leaves to eat.

Sociable - Real-world elks are social and stay in herds to protect themselves from predators. When you browse the web you are also a social creature, often using social networks, or other sites whose content is created by its users, as sources of information.

Specialised - Web Elks perform best when they focus on one thing at a time, rather than trying to multitask. Just as the real-world Elk is perfectly specialised for its environment, you have learned that while the web makes it possible to multitask, it’s not always the best approach.

Googlevoice, or, Lost in Transcription

So, in the interest of exploring the entire range of somewhat silly google products that may or may not improve my life, I signed up for googlevoice, and thereby googlevoicemail. I feel like I haven't explored all of the services involved (at least I think I haven't), but voice is definitely useful for when I'm at work without mys cellphone and need to make a long distance call. I just plug in the number I want to call online, and it rings my desk phone (which I had to set up, a simple procedure).

The voicemail service, however, is basically a good thought that doesn't entirely float my boat. I would love to have transcriptions of my voicemails, but the transcription algorithm or whatever just doesn't work that great. At least not for message-leavers without perfect diction (or with a sense of humor). Here is the transcript of a voicemail from Dan, telling me that he was coming home, that it's very nice out, trying to figure out where I was, and subsequently saying heck with it, he was coming home anyway. More or less:

Hey Pat, F, F, F, F. A. So, okay now. I've heard your message and I approved just trying to figure out where you are. It's a beautiful day. If you were over at the house thinking I was going to drop by if you could be a beautiful day, but I would go home. Viruses, Jeff, I was just like to away if you could do the big day, but it's I was. Barry.

The "FFFFA" was actually him laughing. Thank heavens I can still playback an audio file, too.

LC-Primary Sources

I recently became more interested in exploring the Library of Congress both as a resource, an entity, and (because everything is right now) as a place to potentially work. Today I ran across this in my news feed: The Library of Congress Teacher's Page. It's intended to provide primary sources for the typical classroom lesson, and dabbles in most of the standard themes we all went through in school.

Several things struck me immediately. First, there are pre-constructed lesson plans available (there's not log in to the site, which is nice. Yay free information!). Now this may just be me, but I'd be irked if I knew my teacher was pulling something straight off the internet. However, using some of these for ideas and as support could be good. An example:

I'm interested in WWII, so I browse down the lesson plan list (by theme) to there, and find... mostly sources from the great depression. Hm. Actually there's nothing from the war in there, so I try "What is an American." This gets me a reference to de Crevecoeur (surprise), and some "life history" stories collected by the WPA. There's also an extensive, drawn out lesson plan, which (dear god) takes up classes from September to June! eesh. In any case, a teacher who knows what they want to present to the class could use the lesson plan themes to track down the sources. Kind of neat, but like most things on the internet, a lot of links to click through to find what you want.

A simple search using the search box on the front page brings up a few more hits for "World War Two", but it's still all within lesson plans and feels like it's being handed to me: This is what you should know! *ribbon on top* The point of the Teacher pages is primary sources, and if you dig a little you can get to a good chunk of information, but it can't possibly be everything the Library has. However, I do definitely support using primary sources for research, as they allow students to put more effort into reading and analyzing, unlike standard textbooks. Students will also get first hand perspectives and different voices from a primary source, which makes the experience of learning less monotonous, and hopefully more engaging.

Without the structure of a lesson plan, I think it's wildly entertaining to just browse the collections. And just in case everything the Library has isn't enough, they provide a nicely selected set of links from the outside.

Brevity and selection may be hard for me...

Alright, here's a post at last! I've been meaning to write an actual post for a while now, and have a list of subjects to discuss, but what actually spurred me to get all this down was a massive reading list on google reader this morning and a potential library job in my future. So, here's a run down of a few things I found interesting:

INTERNETS
Among all the sites on the web that "foster the qualities of 'innovation, creativity, active participation, and collaboration'" (according to AASL through SLJ) are a few of those that I've recently been prodding. Certainly most of the sites listed are more traditionally educational that Facebook, Google Reader and Twitter, but I appreciate the recognition of alternative learning resources. GReader and Twitter in particular are great for finding and following interesting feeds (and twits, as I like to call them. "tweeting" is just so... cute?). Clicking through links and finding more and more information can be very addictive, as demonstrated by the massive number of tabs I have open continuously.
Also on the subject of internets and social sites, apparently tagging is becoming important as a reader advisory (RA) practice. Being kind of new to this, I don't know much about RA in general, but I'd bet it's a lot about knowing your collection (and beyond) and being able to help patrons (or whoever) find things that are good for them. Apart from *actually* knowing every book you've got, there are always jacket blurbs and being familiar with an author, if not the book specifically, to help with advising on a reading choice. That said, if tagging were to be used on books, it would be.. why, it would be like the subject index in the card catalog. No? Nevertheless, imagine having a tag cloud for your library, like mine, here and having everyone find books they might like through it.

And also in the world of reference and internet and research, credo reference is gathering reference engines and working with IP adresses to make getting access easier. Haven't had a chance to look into it yet, but definitely something to keep in mind.

BOOKS
In my absence from the public library scene, it appears that a new genre has developed. Mostly blamed on the massive trend towards porphyria in fiction, urban fantasy also covers other elements of fantasy in a gritty, reality-based settting. Presumably, this brings the traditional fantasy world closer to home, elevating the believability factor and perhaps making it easy to approach for readers today.

Here's a list of books about, well, books, from Library Journal. I can't say a lot about it because I haven't read them yet, but several will certainly make it to my (epically long) "read right after I've read all these other books" list. Someday, someday.

Whoa, Internet spaz-fest

It's always oddly awkward starting a blog. You have to find something enticing to draw people in, not over-do it, don't post every hour, get your formatting decent (without posting about what a hassle that's been)... So here I am, guys.
I'm also here:
Facebook (for RL friends only)
Delicious
Twitter
LibraryThing