This past weekend marked the second major snowstorm to hit Utah for the 12/13 season. With more resorts spinning their lifts, it’s a safe bet that fall is officially behind us and winter is here to stay. Needless to say, the good people over at Ski Utah were chomping at the bit to get their first turns of the season. Above is an edit they put together featuring a few preseason pow turns up at Powder Mountain.
As usual, Google is keeping us on our toes with yet another change to their products just in time for the holiday shopping season. Google said in a blog post earlier this year that as of “October 17, Google Shopping results in the US will come only from merchants who are Product Listing Ads advertisers.” The Google Product Search was once a wonderful source of free traffic to merchant websites that has recently been transformed into Google Shopping, a paid service to add to your marketing budget.
This one could be a head scratcher for some of you, especially if you are like me and don’t frequently spend a lot of time in linux. I typically leave that to the full time admins and our dev team. There are times when I do need to jump in and help out when we are under a tight deadline. When you gotta move files around or create backups, tar is the best way I have found to archive your files. It ican be very powerful as it allows you apply algorithms when compressing or decompressing your files.
Earlier, I was using tar -cfz sometarfile.tar.gz somedirectory to archive a directory, and tar threw a fit on me; tar: mytarfile.tar.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. Bummer.
A quick search revealed the true nature of the problem:
When you use the ‘-f’ option you need to place the file name directly after that option. The first command I used was looking for a file called sometarfile.tar.gz to add to an archive file called z. Since the mytarfile.tar.gz didn’t exist, tar couldn’t locate, or stat, the file. Thus the reason for the error.
Here is The Correct Method:
tar -czf mytarfile.tar.gz mydirectory
Thanks to GNU’s tar documentation over here I found my answer.
This is an article that I have saved in some for or another as I send it out whenever we begin testing an application to the clients. I feel a little silly posting this but I figure that it might help someone develop a more efficient dialogue with their client or other team members.
While we try to mitigate bugs prior to releasing code for testing using a variety of testing methods, bugs happen. Bugs can occur live environments, too, often due to outside circumstances sometimes beyond anyone’s control. One of the key elements to getting things fixed quickly is giving a thorough account of WTF happened. Here are four tips that can really increase the speed that bugs are addressed and eliminated.
1. Specify the Timeline
Note when you first noticed the error as well as when things were last working. This is simple and can really provide the person responsible for fixing the problem with some very important information.
2. Specify the OS/Device/Browser
Providing the Operating System, Device and the Browser you were using when the error happened will help your developer to eliminate Cross Platform or Cross Browser issues.
3. Specify What You Were Doing When The Error Occurred
Providing information about what you where doing at the time will be beneficial. If the issue was on a website, please provide the URL as well. This will allow your developer to replicate the problem, it can be difficult to fix problems that you cannot replicate.
4. Describe What You Saw
Tell us what you are seeing. A picture is worth a thousand words- if you have a screen shot tool, please take a snapshot. If you saw an error copy and paste the error. This always helps your developer understand the nature of the problem. Finally if you have any observations be as specific as possible about those. Saying something like “The product feed is broken” is not as helpful saying something more specific. For example “The product feed does not appear to be pulling any of the Men’s Jackets”
One final thought… it is not a bug if it was functionality that was not intended in the release you are addressing- a bug is intended functionality that is broken. That is an article for another time though.
I like to use terminal on my Mac. It can be much faster and sometimes I like the soothing green glow of the Homebrew theme. It takes me back to the days when my prized possession was an Apple IIc, a computer that was cool because it was a tremendous upgrade from my TRS-80… and it had a handle. The monitor that it came with was a green monochrome monitor that made me feel like Matthew Broderick in War Games.
Wget is a linux based too that I have found to be a huge time saver when I need to grab large files from another server quickly. It may not be as powerful as using CURL and it certainly has a few limitations, but if you understand what the hell this article is about you probably know this already.
NOTE: You may need to install Xcode on your machine first. Don’t ask me why.
Steps To Installing wget On Your Mac
- Grab the latest copy from the official GNU Project. At this time we are looking at version 1.4.
- Unzip the file.
- Launch Terminal and navigate to the folder wget is located in. For example cd ~/desktop/downloads/wget-1.14
- Next you will need to configure the package for you machine and install it typing the following command: ./configure
- After the packages have been configured type: make
- After your files have been copied into a single binary file for use on your Mac type: sudo make install
- You may be prompted for a password. Enter your admin pass.
Thats all there is to it! Now you can grab that large DB backup file from your server for testing, quickly download the latest version of WordPress from command line quickly and easily.
Please note that this worked for me. It is not my responsibility if your FUBAR your computer. Always back-up!
While most will agree that the snow season so far has been a wash, there have been some good turns to be had. Last Friday we had a nice little system move in and dump close to 2 feet of Utah’s finest up in the hills. So of course we did what any self-respecting ski-bums would do; put up the “Gone Skiing” sign at the office, pushed our meetings to Monday, and broke out the snorkel.
Here’s Nate getting some in Main Bowl at Deer Valley:
As anyone in the office will attest to, I am a stickler when it comes to typography. Poor typography can single handedly ruin a design, and is a tell-tell sign whether or not a designer is worth their weight. Ever since the advent of “web design” bringing good typography to the web has been a struggle for designers. There’s a constant battle between aesthetics and accessibility, and most of the time accessibility wins out. For good reason. With the introduction of CSS (cascading style sheets) our ability to manipulate and set type on the web has been greatly improved. However designers are still greatly restricted when selecting fonts for the web.
When it comes down to it designers basically have two choices: Helvetica and Georgia. While both are excellent type specimens, using the same two fonts over and over can be quite the buzzkill. Up until recently, if you wanted to use a non-web font your only option was to export the text as an image. This is generally not regarded as good practice for a couple of reasons: 1) Text in as images are not accessible. The text isn’t read by search engines and in turn kills your SEO. 2) The more images you have on a site, the longer the site takes to load.
The good news is that there has been quite a bit of innovation in the web font world as of late. While all of these solutions are improvements, they all come with their fair share of drawbacks. I’ll briefly detail some of the pros and cons of the most popular methods.
- 1. @font-face: A simple line of CSS allows you to embed fonts into a page. Seems simple enough, right? Wrong. Besides the fact that Internet Explorer doesn’t support it (big surprise) the @font-face opens up a whole can of worms when it comes to licensing issues. By embedding fonts on a webpage, anyone that accesses that page has full access to the font files. While this is good news for people looking to build their font library, it is certainly bad news for the already unsung font designer.
- 2. .EOT (embedded open type): Microsoft’s version of @font-face has been around since IE4. While Microsoft has opened up licensing for other browsers, no way in Hell is Mozilla or Apple going to adopt Microsoft’s way of doing things at this point in the game.
- 5. .webfont proposal: Widely regarded among type foundries as one of the best proposed solutions, .webfont would be comprised of a compressed file along with a data file. Within the file are permissions that would be read by the browser and displayed. While this seems like a winner, the proposal is still waiting to be approved by the w3c. Currently no browsers support .webfont.
For more in depth reading in the world of web fonts, visit the great I Love Typography. Web standards expertJeffery Zeldman also has a great write up on web fonts, and for more information on using Cufón, designer Cameran Moll provides a good tutorial.
Perhaps one of the most surefire ways to simultaneously elicit emotions of rage and despair in your designer is to remark “I’ll know it when I see it.” To a designer, that roughly translates into, “I have no idea what I want, but I’ll expect you to produce revision after revision until we run out of time and money settling on something neither of us are that happy with.” Simply put, “I’ll know it when I see it” kills dialogue and puts the designer / client relationship on a fast track to Revision Hell, complete with micro-management and an endless sea of comps.
Truth is, knowing it when you see it is a very rare occurrence. Think about it. Did you know that Google would soon be one of the fastest growing, most innovative companies to exist the very first time you Google’d something? Chances are probably not. And if you did, than you probably invested some cash and are now off sailing somewhere in the South Pacific, certainly not piddling your time away reading this blog.
While it may sound like we’re being a little hard on clients, ultimately it is our responsibility to prevent these 7 deadly words. In reality, most clients don’t know what they are looking for, nor do they possess the creative vocabulary to tell us. Which is why they are coming to us in the first place. After all, the ability to interpret a client’s somewhat clumsy analysis of what they need into a concise visual masterpiece is what separates “real” designers from those $99 online Design-R-Us guys.
Asking the right questions, listening to our clients, and setting boundaries are all necessary ingredients for a successful relationship, be it business or personal. We must be able to create an active dialogue among clients by asking appropriate, thought provoking questions. Furthermore, once a dialogue has been initiated listening to both what the client is and is not saying is critical to ensuring that pertinent info isn’t falling through the cracks. And finally, we must set clear boundaries for clients to give ourselves the necessary freedoms to do what we do best.
So the next time a client responds with “I’ll know it when I see it,” slowly put down your exacto knife, take a deep breath, and run for the hills.
Perhaps one of potent tools a designer can possess, in addition to good typography of course, is a thorough understanding of the Gestalt Principles. Around 1900 German & Austrian scientists began to formulate concepts based on humans tendencies to seek patterns, and specifically how we organize and process graphic data through these patterns. The theory and data they derived is particularly important to those in the visual arts field and most notably Graphic Designers. The Gestalt Theory states: 1) The parts of a visual image may be considered analyzed and evaluated as distinct components. 2) The whole of a visual image is different from and greater than the sum of it’s parts.
For instance, when one looks at a poster they may notice the type, color, and any visual elements the designer chose to employ. Each element can be individually admired, yet when combined they take on a coherent identity with each part adding to the other. Furthermore, we have been conditioned to seek visual patterns, which informs us that these elements, though all separate, should be viewed as a whole, completing the formula for building a poster. By equipping ourselves with a thorough knowledge and understanding of these principles, we can predict how our audience will view and react to our work.
The 7 Gestalt Principals
- Figure / Ground – the law of perception that allows us to read imagery through contrasting elements.
- Equilibrium – the psychology that tends toward order, balance, and efficiency. Humans interpret complex natural phenomena as simple and complete.
- Isomorphic Correspondence – the relationship between structural characteristics and behavioral characteristics. Experiences of people, both physical and psychological are recalled and triggered by specific events.
- Closure – closed shapes are more stable than unclosed shapes. Humans have tendencies to close and complete gaps and unfinished forms.
- Proximity – Perceptual groupings are favored according to closeness of parts. Nearer parts form groups and unite visually.
- Continuation – The eye will follow or continue along a straight line or curve.
- Similarity – Similar objects defined by shape, size, color, and direction will be perceived in groups and units.