Getting up to speed on CSS tools

I did this backwards. It should have been mixins, Sass, Smacss, Compass, Singularity. Then again, sometimes starting and the end and working your way back lets you see the bigger picture and understand how it all fits together. Says the girl who started Drupal with core contributions.

Singularity (compass extension)- ratio-based grids (quick walkthrough video here), very easy to make different widths $grids: 1 2 3 2; Also can use px, pt. Integrates with breakpoint- add an @include breakpoint(30em){@include grid-span(2, 3);}. Very cool, super easy way to get responsive design out fast.

Mixins-  A mixin is an at-rule used to define a ruleset than can then be *reused* in other rulesets. Yay reusable code. I think mostly as a n00b I'm always surprised when things like this aren't a given- it makes perfect sense to be able to define a thing and then plug it in wherever you need that thing. But is this the same thing as the mixins Compass is using?

/* define a mixin */
@mixin .muffinstyle {
display: inline-block;
background-color: blue;
}
/* use a mixin */

p .bakery {
include: .muffinstyle;
border: 1px solid red;
}


ok, Stackoverflow question on the CSS at-rule here. So basically anything preceded by an @ is an instruction for the user agent, rather than styling rulesets. I've been using @media, @font-face and so on, but hadn't really thought about the construct itself. Here's MDN on at-rules and W3C on CSS syntax (this one's really helpful). There's a very handy graphic and description here on CSS statements and their subsets, at-rules and rulesets.

Compass- Ok, so there are CSS mixins, then there are Compass mixins... which are just a predefined set of CSS mixins? oh. And then Singularity pairs with Compass. I get it. /several hours of digging and reading later.

Sass- This also makes all kinds of sense. Things like variables to hold info in a more logical spot while you're writing, then output a fully fleshed out CSS file at the end. Saves on typing, mistakes, and again with the reusable code. Compass is for writing Sass. Got it. Wow, nesting. So logical, so tidy. Ah, and we're on the new version that uses curly braces, which seems a lot better than just indenting anyway. I do not generally approve of dropping semi-colons and such even if it *is* more minimalist.

Smacss- I really appreciate this- organizing, categorizing, approaching css in a logical fashion rather than throwing properties left and right and hoping it all works out. See my next post on approaching a problem, too. I might disagree with a couple things Snook says (and this book is a little old already), but his general point is spot on. I think this will fit into my brain even better after my next two or three tabs, too... Things start getting interesting once we drill down to the "module" level. Goals: increase semantics and decrease reliance on specific HTML

Next: More depth from Legacy CSS with Sass and SMACSS and modular SASS development using SMACSS and BEM.

In other predictable news, something here needed homebrew to install... I think it was a Ruby update. I have Ruby 1.8.7, but would like to have the current. Probably doesn't matter. But I think to update I need homebrew and homebrew last I checked needed xcode and 10.6.8 does not the xcode have. BUT. I think I can install the sass/singularity/compass package with just ruby. I hope. Later. Not now. Because this is always ridiculous, and generally why I'd rather stick with simple, low-level stuff.

Next: Creating a Drupal 8 Theme with Sass, Singularity & Breakpoint

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...

Sketchy resume design

he most important thing to me right now is keeping my perspective. If my goals aren't in clear sight, I get massive scope creep and wind up trying to learn Unix instead of just working on my HTML project (see hereabouts). However, at this stage it's also important for me to be exploring, dabbling, learning everything I can, and even when projects don't work out or seem unreasonable in some way, I do still learn something from the experience.

Take the newfangled resume I created, for instance. It didn't come out quite as responsive as I hoped, largely because of some finicky elements and my avoidance of media breakpoints. What was interesting, however, was talking to a friend who is familiar with hiring processes at a very prominent tech company. He indicated that a good looking resume is nice and all, but what's most important is a) contact info and b) recent experience. The rest is just noise.

In all fairness, programmers are not necessarily interested in shmancy presentation and part of my goal was showing web design skills. However that was pretty irrelevant when I realized I didn't really want to host my resume publicly on my website.

The process was kind of interesting. I had a basic idea what I wanted to do, drew up some rough sketches (above) with actual pencil and paper (I can't handle initial sketching on a screen, sort of like how I just can't stand e-books. I'm a holdover, I know.) Then I entered my content in an HTML document, put it into sections and got the basic structure marked up. From there it was all about CSS, I barely touched the HTML document again except to add some id attributes. Below are some screencaps of the layout along the way, shown with boxes and dotted borders so I could keep track of what element was where. I admit I went a little crazy with the colors...

And yes, I blurred them, because the text isn't the point here. Some of my original ideas were even more abstract, but it became clear that I did need to say something about what skills came from which job. I considered doing this with some sort of clever mouseover thing, where a line from skill to experience would pop up, but decided that was definitely too fussy.

Anywho, one important question that came up in the process was how relative placement communicated relationship and meaning of each element. Elements next to each other would speak to each other in some way and have some relationship. I think I may just go back to my old, boring resume (though with less hideous layout, at least).

... After all that, I'm very done with this stage. Anyone have experience with designed v. functional resumes? Does a different layout affect your opinion of identical content?

EDIT: on structure, I leaned on the HTML outline concept, but didn't include this link here, I don't think.

Career realization orchestration

oday I went on a whirlwind tour of small web design firms in the DC area... via their websites. I'm not entirely certain where I'll wind up working next, but I wanted to get an idea of the playing field, who does what, who has which skills and so on. A quick Google search netted me about a dozen firms to browse through, cross-referenced to some Yelp reviews and Angie's List. I realized partway through that in the longterm I want to be working on a single project, e.g. for an organization developing and maintaining a service, product, brand or mission. However, until I'm at that stage, I do want to build or contribute to as many small things as I can to get more experience in a variety of languages, platforms, aspects, tools, ad infinitum.

Anywho. Between browsing all those design firm's sites and clicking any link with the word "design," I've been all over the place lately. My favorite sites are usually minimal, clean and simple, no clutter, a touch of flashy stuff (watch the "Silver and Light" video, this guy is great), hand-drawn elements, and a limited palette (though I might also go for lightly cluttered and slightly "hipster").

EDIT: I started an account on Bo.lt, but am not entirely impressed with the service. The idea is that they archive screenshots and entire copies of webpages, hence, good for a design inspiration collection. Adding pages can be glitchy, and it still doesn't have an easy "embed collection" sort of thing. Picasa (despite having irritatingly merged with G+) does support embedded slideshows, but generates an embeddable version itself. However, I'm not actually using Boltnet for its original intended purpose.

However, I ran across a lot of sites using carousels at the top of the page, and I have to say that was a big turn off. Knowing how popular they are, I'm pretty forgiving, but good lord. If I'm disinclined to actually look at a scrolling reel of content, I can't imagine that the average user will give it any thought. And a carousel is like the A1 photo; it takes up the majority of the space above the fold, which means that space is completely wasted if no one looks at it, much less clicks on the content flying past.

All of this has been discussed and debated quite a lot across the web. The general conclusions I found are that carousels stick around because you can sort of cram more content into a single space, and because they've become a staple. The problem with reading up on this is that while every design firm and marketing agency has done their own usability testing, that data is usually kept private.

The UX site on Stack Exchange has some discussion on the effectiveness of carousels, to wit, whether rotating content nets a site any conversion (meaning the user does what the marketer is hoping they'll do: convert from just browsing to being an active user or a paying customer). I can't remember how I found this article, but it's a good, recent roundup of tidbits on banner blindness, user control and contentless content. And from there I found Jakob Nielsen's denunciation of the autoforwarding carousel (though I was disappointed to find that the main example of user testing was literally user testing. One user.)

Anyone have a good way to collect inspiration online [that isn't Pinterest]?

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?

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.

The closest thing to home: Sharp residence, London

I see a lot of interior design ideas come across the web and in magazines, but this is the first that is really close to what I would like in my living room. There are a few key elements here:

• Built-in bookshelves. I require many, many of these for my books.
  
• Interesting design elements. Angles, antique ceilings, fireplaces, nooks and so on.
• Contrasting walls. I keep considering wallpaper, but I think paint is the way to go, because...
• Minimalism. Keeping it simple, even if there's some clutter.
• Warm, home like feeling. Generally attained through well-controlled clutter and lush fabrics, shiny metals.
• Well designed furniture and art pieces. I'd like to collect these from artist friends and around the world.
  

So, here, thanks to Christopher and Suzanne Sharp putting it together, Vogue's Francois Halard shooting it (full story behind link), and ApartmentTherapy posting the image, is the best representation of my vague ideas for the decoration of a living space:

In fact, the only thing in this image I really don't like are the two yellow chairs in the foreground. Otherwise, I would just have my own interpretations of what's present here.