Uncategorized
date: 2012/02/02
—
In a graduate seminar this semester I am reading a book by Kenneth Goldsmith called Uncreative Writing. He teaches poetry at UPenn a class of the same name where he tells his students that they will not be doing any creative writing of any kind, that everything will be stolen and plagiarized, two big no-no's in academia. In fact his final assignment is to purchase a term paper from a "paper mill" and then defend it.
SPLIT_SUMMARY_BEFORE_THIS
I have so far read the introduction and the 1st chapter. Some of my classmates complain about the mechanics of his writing but to be honest I am more interested in the ideas and I did not notice this in a negative way.
To me this book is very smart. He seems to be taking some postmodern ideas such as that of Delueze's Rhizome, looking to visual art as a reference, and creating a poetic textual mash-up. It reminds me of some of the great enthusiasm and interest in the early internet in terms of hyper-textuality using the Rhizome metaphor and the hope for cyberspace outlined à la Mondo2000. It seems that thoughts and spaces such as the LambdaMOO seem to be reused today as maybe literature is falling way behind.
When I think about this though, I do not think that this is exactly the case. What I think about is all of the open source projects and movements that have be archiving not just classic texts but any texts they can get their virtual hands on.
And so, this book proposes, we should not be creating any new texts. There is enough of that already, but rather we should remix, mashup, and reconfigure such texts into expressions of the the now or contemporary society.
On a side note, I am very interested and influenced by this book because of some experiments I did over the summer during my residency at the Institute for the Arts and the Humanities at Penn State. I was interested in how the rhizome or cyborg might manifest in the process of generating a traditional thesis in an non-traditional way. I am seeing a lot of connections between my experiment and what Goldsmith is speaking of. I feel that it is giving me a better context and way of describing these methods I was using. Right now these are just some fleeting thoughts. I hope to further reflect on these ideas and more specifically identify some of the intersections in the near future.
Love this book so far. I highly recommend it. I am also reading it on kindle which is fun, however, it seems that the fact that it is linear and not "hyperlinked" is a missed opportunity.
-James
Uncategorized
You may not want to hear this, but step away from the marketing automation tools and start offering genuine content that is of use to others.
It might just be the best thing you did for your career. I know it was for mine.
But, beyond that what is in it for you?
Great question, thanks for asking.
I have outlined 8 solid reasons why you should consider it.
Why 8? Glad you asked. First, gotta love base-2. Second, I am avoiding the internet marketing patent trolls who have a patent on the number 10.
And off we go.
#8: "Get Out of the Building" –Steve Blank
Probably the most compelling reason to start writing about your work is something I have gotten from reading Steve Blank's book, The Startup Owner's Manual.
In his book he advocates that founders spend way too much time making huge assumptions about what their target market wants. He suggests to get out of the building, interview real users with real pain points and then to return to apply what you have learned.
This is an iterative process. You don't just go out and do it once.
Although you don't physically get out of the building, blogging in a sense accomplishes some of the same goals.
You put your work out there so it is available for review by other developers at all sorts of skill levels. From feedback you learn quickly how you might not be explaining things clearly. From more advanced devs you will gain great insights into better workflows and better ways to approach things.
<%= partial(:tweetthis, :locals => :quote => "Get out of the building", :person => "Steve Blank", :twitter_account => "sgblank") %>
And the best thing is that all of these come from people outside of your dev team, co-workers, mastermind group or whatever.
If you want to see if what you are doing is marketable, get out there and write about it. If people start responding, odds are there is a market for it.
#7: It is Huge Productivity Saver
Use case 1: I forget something. Pretty awesome I wrote about it, know exactly where it is and in what part of that blog article is that specific bit of information or boilerplate is that I want to copy.
Use case 2: Someone asks me something. I send them a link to an article I already wrote. Done.
Use case 3: Many people ask me a question. I write an article about it and then send them the answer. Now I answered 5 questions and all future same questions at the same time.
#6: The Business Card is Dead
I mean, who has business cards anymore? I know I don't.
Just make sure you pick an awesome domain name. Usually your name simple and sweet is best: I am using jamesstone.co
<%= partial(:tweetthis, :locals => :quote => "The business card is dead") %>
Before I was using manofstone.com, which was a nickname I inherited in the Animation Program at San Jose State.
I asked a UX Designer friend about manofstone recently and he said, "What does man of stone tell me about you? Nothing really."
Point taken, hence jamesstone.co, moving on…
#5: The Resume… er Linked In is Dead
In my opinion both are dead. The latter can be good for networking but as a resume or getting me a job as itself it has been 100% ineffective for me thus far.
Sure, sometimes these are necessary evils to get a job at some point, but your own on point blog is going to be much better.
Lets break it down:
1) Consists of technologies and topics that interest you
2) Shows that you are well versed in your focus area
3) Allows people to easily find you. Google "james stone zurb foundation" and see for yourself
#4: Getting Involved with the OS Community
Github is awesome and so is Stack Overflow. But here is the thing, if you want get involved and never write about it, it is unlikely anyone will know.
With the exception of those going through your late night Pull Request of course. And if you are doing something awesome, they should be writing about it in their blog too.
So, when you add a new feature, crush a significant bug, write about it. Write about what the problem was, how you arrived at your solution and how you solved it.
Not only will it draw more attention to the Open Source project you are working on, which is awesome, but it will also serve as a record as to how you solved that problem.
Have you created your own OS project? Great. Maybe you put together some documentation, threw together a site and published it for free on gh_pages.
If not, go do that now.
Then talk about the project on your blog and have a launch. Talk about your releases. If you need a good example, check out how ZURB talks about their releases on their blog.
It makes the project look great.
It makes the contributors look great.
It makes you look great.
Its a win-win-win situation.
#3: Find your Rat People
Paul Jarvis has a great post about what he calls his Rat People. He loves rats and tends to attract people who love rats too.
Rat haters? Well, not so much.
The same thing applies to you. By writing about what you are working on, what you are passionate about and technologies you love, you are likely to attract people with similar interests.
<%= partial(:tweetthis, :locals => :quote => "Find your rat people", :person => "Paul Jarvis", :twitter_account => "pjrvs") %>
Love LAMP hate .NET? No problem.
Love .NET hate LAMP? Same thing applies.
Want to take this to the extreme? Be sure to check out Jarvis' Work Manifesto.
#2: SEO is Dead
Well, not exactly. But Google's stance is that if you are creating quality content that is genuinely useful to others then you should be good.
So going forward as algorithms are getting better, you should assume your newly acquired growth hacks are going to become less and less useful. Maybe you will find a new bag of tricks, but it is a never ending battle.
Here is my argument. Useful information is timeless. It doesn't really matter how you approach it. You want to be writing all the time and it is this aggregation of great content that starts to build an audience around you.
Plants vs. Zombies 2 Example: You must have a variety of plants growing all the time in your Zen Garden. Its no good to have the same plant boosted at the same time. You need to have 2 or 3 different ones to pass those really hard levels most of the time. You don't want to end up with non-boosted plants, because that is just going to burn all through all of your coins.
Same thing in blogging. Write about everything at first, then you will start to find focus. This will evolve and change paths as you keep writing, but just keep at it.
What about that new level that looks like medieval castles? Looks pretty awesome to me.
This is some new technology you are interested in and want to try out. Just write about why you are interested in it.
Odds are, there are other people thinking exactly the same thing too.
#1: Start with WordPress, Level-up Later
I know, WordPress. It is totally selling out to the man. Super mainstream.
I will let you in on a little secret, I started out with WordPress too.
I suggest you do the same.
Here was the process.
- Created some lame wordpress site
- Started writing
- Found some better looking theme
- It started to better represent what I was doing
- Started modifying these themes I found
- Kept writing about things
- Went out on a limb and jumped into Ruby Middleman, glad I did
- Continue to build out my site with my favorite technologies
- Looking at Assemble.io for fun
Is Assemble.io better than Middleman? Who cares. Here is the point.
You can start with WordPress and then run a script to export all of your articles in markdown format. Easy way out.
Then you can move to something with more geek cred, maybe that is OctoPress or Middleman if you are on Ruby, Pelican if you are on Python, or Assemble.io if you are on node. There are hybrids such as hardwired or stamatic and different commercial and open source projects that you can tie into.
Go with whatever seems right. You can deploy to Heroku or Github Pages or whatever works best for you. Write about why you made those decisions.
At this point you can start to push the performance through the roof. Maybe your site started out loading 4 seconds, soon it will be under 2. Maybe 1/2 second once you go static. Go crazy.
Think of it as a test bed, where you can push the performance of what you want to do and create something that represents you as an individual. Things you care about. Examples of your work. Things that you have complete creative ownership in.
Then, next time you are looking for a job, send them a link to your blog. It will likely speak for itself.
With time, you might find that people are approaching you. This is the end goal and what you want to have happen.
Which brings us to Growth Hacking…
I won't get up on a soap box here, but here is the thing. If your twitter-bot ads me and does some weird robo-behavior I am going to be on to it.
Why? How do I know?
I am a programmer. We all have a sixth-sense about this kind of stuff. Probably because we either 1) wrote that script 2) know the person who wrote that script 3) had a dream about writing a script like that or 4) thought, man I am pretty lazy, maybe I should automate this friend making business.
Point being, go use that stuff on people that don't know better or for some other purpose. Or better yet maybe consider not using it at all.
If you really want to impress other devs (likely the people that will be actually hiring you), go do cool stuff, share your work, carry on a conversation and move on to the next thing.
I wish you the best of luck and can't wait to read about what you are up to.
Unless you are doing .NET. In which case I am not really into it. No offense.
But, if you have read this far, I am sure you can imagine there are a bunch of other people really fired up about it. Go spread your .NETness or LAMPness or MEANness with the world. Go do it with confidence that there are others just waiting for you to write about it.
So what about you? Have you set up a dev blog and had a good experience? Not so much? Do you disagree with me about blogging or automation/growth hacks? Lets talk about it in the comments.
Uncategorized, zurb-foundation
In an article CSS Frameworks + CSS Reset: Design From Scratch author Sven Lennartz suggests there are 6 major reasons to avoid CSS Frameworks completely.
In this article I will go through each “Myth” one by one and show you, at least in the case of ZURB Foundation 5, that this is no longer the case today.
(Yes, I know this article is from ’07, but it is highly ranked in Google and is worth discussing)
Myth 1: “You need time to fully understand the framework”
This is simply not true today. ZURB Foundation uses easy to remember class names that do exactly what you would expect. You do have to understand modern grid systems, which can be an effort in itself, but that is going to be the case with all modern web sites. If you want to learn more about how to use the ZURB Foundation Grid, check out my Screencast on YouTube.
Myth 2: “You need a close familiarity with your code’s architecture”
Lennartz suggests that you “need a profound understanding of your code” in order to use CSS frameworks. Today, all of ZURB Foundation’s components can be used by default simply by adding in data attributes into your existing HTML. If you want to take it to the next level, you can definitely learn how to customize things with CSS or JavaScript / jQuery but that is completely optional.
Myth 3: “You might inherit someone’s bugs or mistakes”
In ZURB Foundation’s current state, being driven by Bower you have a lot of flexibility. Just with any open source project it is quite possible to get bugs in the latest releases, but the ZURB Foundation Team has been very good about addressing bug fixes in a very timely matter. I seen them sometimes push out a new version the very same day to address a bug fix in a x.1 release.
If you crave stability, you can always get specific in Bower. How specific? Really specific. You can chose to load a specific branch, tag or version of ZURB Foundation via Bower.
Go crazy, set your version to whatever works best for your project and then carefully update your project as you move to the next version. Stay a couple versions back. Use Foundation 4. These are all options with the new Bower workflow.
Myth 4: “You get a bloated source code”
Foundation since at least version 3 compartmentalized its source code and made it work well with things such as the Rails Asset Pipeline (Sprockets). This allows you to remove JavaScript components you are not using.
Why not go Sass only? Did you know that a lot of Foundation components don’t need even one line of JavaScript?
It doesn’t get any more minimal than that.
Myth 5: “CSS can not be framed semantically”
As of Foundation 4 you can use Sass Mixins to frame your HTML source semantically. The only very slight exception of this is you still need the concept of a row or container, but that is going to be the case in nearly all situations you encounter. If you want to take a look at how to use sass mixins in this way, check out my tutorial to create Semantic-UI Style markup using Foundation. Of course you are not limited to <div> tags and you can use all of the <nav> <section> and <article> tags you want.
Myth 6: “Ignoring the uniqueness of your projects”
Lennartz continues in this myth to address the idea of uniqueness in projects. With ZURB Foundation you can radically change the look and feel of the framework. Furthermore, you are able to copy and modify your _setings.scss file to start your project from a different perspective.
“Craft”
The biggest myth of all is that somehow using a CSS Framework is somehow poor craft. There are places for this. If you are working on a large scale project then you probably don’t need a framework. Or you are using a homebrew in-house version. No problem.
Odds are, you are not going to be building things from the ground up by yourself in this situation anyways. The biggest reason that I choose to use the ZURB Foundation 5 framework is because ZURB really knows their stuff. If you really want to learn about modern UX, UI and design it is a really good place to start. You can even jump into the source and learn how they are doing the things they are doing.
Maybe you will even develop a preference and build a your own personal modification of Foundation. Or start it with more advanced frameworks such as Bourbon + Neat or Inuit CSS.
The argument about craft and CSS frameworks all depends on how you use them.
Build well designed, fast loading and efficient sites and apps.
Don’t worry about the CSS Police.
Odds are, they are not your ideal demographic anyways. Unless of course you are building some sort of product for people who demand pure-artesian-hand-crafted-CSS. In that case, by all means, build everything by hand every single time.
So what do you think? Have CSS Frameworks improved since 2007? Do you value “craft” over frameworks? If so let me know why in the comments.
Uncategorized, zurb-foundation
ZURB is a self professed team of "T-Shaped Designers that help grow businesses" and doesn't fit into typical agency categories. They have worked with a ton of startups since 1998 and have help build or refine some of the greatest UX you have experienced across names big and small.
They are situated geographically in the city of Campbell, which is a small community in the South Bay Area which is in the heart of the Silicon Valley. One of the things that makes ZURB very unique is how transparent they are in their process and their tools.
If you are interested in Responsive Web Design or User Experience or even Sketching Wireframes ZURB has you covered. They not only post amazing articles that offer a lot of value and insight but they also host free events such as their Soapbox and the Foundation Meetup allowing the community to tap into their hive mind and get a glimpse at how the masters work at their craft.
ZURB Foundation
So you might be thinking that Foundation looks a lot like Twitter Bootstrap. Well there is a lot of history there and a common linage that leads back to ZURB. (If you want to learn more, listen to the Changelog Podcast, episode 112 with Jonathan Smiley and Mark Hays)
A common misconception is that Foundation is for designers and needs a lot of design to work well, where as Bootstrap just looks great out of the box. One can certainly argue that Bootstrap is a little more "designed" out of the box and Foundation looks a little more bare bones.
At first it appears that Bootstrap seems to be clear winner when making a choice. The problem comes later, after implementing Bootstrap on a project and you want to make some large sweeping changes. Sure, this is possible with Bootstrap but it often leads to a lot of overridden CSS or other less graceful solutions.
Foundation uses Sass and allows you to easily and quickly change the color, appearance and style of elements. It is designed to be configurable, flexible and extensible.
Fun?
In my experience, ZURB Foundation is fun to work with. But, lets see if I can qualify why I think it is fun.
You hear a lot of these same types of comparisons with the Ruby language and the Ruby on Rails framework that popularized it. Things like Syntactic Sugar, Magic and Readable are thrown around. It is something that is hard to explain to people who 1) have not programmed in another language that is not so fun like C or Java and 2) moved to Ruby and Ruby on Rails and 3) experienced the culture of Rails.
Coming back to Foundation it is both the syntax, structure of the framework but most importantly the culture that surrounds it that makes it so much fun.
First off, ZURB is a fun company. Look at the bright colors or the playful and energetic writing style they use.
They are passionate, quirky and fun. Just take a look at their about page or one of their ZURB Wired projects where they build out a project for a deserving charity in a company wide 48 hour marathon.
When you look at Bootstrap in comparison, it is not that it is wrong or right it is just that it is a different culture. Bootstrap presents itself as a mature, corporate and mild mannered framework.
Yetis?
Which brings us to the Yeti. Whats up with the Yeti and what does that mean anyways?
Well, ZURB offers a explanation, but I think the Yeti is much more.
The Yeti is really the mascot for ZURB Foundation and is lovingly crafted by some of its best designers. There is even ZURB swag if you are lucky enough to get your hands on it. There are stickers, T-Shirts and other Yeti sightings.
If you want to learn more about ZURB, Yetis and ZURB Foundation I suggest taking a look at their official history.
UPDATE: A special thanks to @Brandon_Arnold for pointing out that ZURB is in all caps.
Uncategorized
I read Mobile First and couldn’t put it down. I won’t lie, at the time with the upcoming release of Zurb Foundation 4 and everyone talking about Mobile First I was more than curious. I recently read it again and everything still rings true today.
The Premise
The overarching idea of the book is quite simple. Approach web design problems as if you are forced with the constraints of designing for a mobile touch enabled device such as the iphone, android or windows phone. This has several benefits including: simplification, elimination of unnecessary features, and being more pleasurable to use. These are just to name a few.
”Mobile First is packed with the best kind of persuasion—persuasion from data, letting the facts shriek for themselves. And it offers the best kind of advice: practical, immediate, user-focused, big-picture stuff that sweats every detail and respects your IQ and your experience as a practitioner.“
– Jeffrey Zerlman, foreword of Mobile First
One of the promises in the foreword by Jeffrey Zerlman is that Luke backs up all of his recommendations with data. Luke does not disappoint in this regard. My kindle/.mobi version has a shortened url (as well as the full reference in an appendix) showing you exactly the web source of the quote or statistic. This is a wonderful thing and brings the accountability of academic papers to the world of startups, web and product design. Bravo. I would love to see this trend continue.
My Favorite Part
I really enjoyed the part in Chapter 2, Constraints, that talks about screen size. Going from a 1024 x 768 screen down to a 320 x 480 pixel screen gives you only about 1/5 the space.
So what about the rest of that stuff? It either has to find a new home or be removed, and Luke reminds us that this is “terrific.”
”This isn’t just an opportunity to create a mobile version of your web product; it’s an opportunity to provide an improved customer experience for your customers.“
In my experience I believe what we are witnessing is mobile ux principals and design patterns coming back up through the ecosystem. This has resulted in a whole new breed of desktop web apps resembling more and more their mobile counterparts.
I believe that easy to use front end frameworks such as Zurb Foundation are making this transition not only easier and faster to implement, but also more consistent in their application.
I think this book offers a wealth of great examples (even if they might be dated) and gives a lot of fantastic advice as to where to look for opportunities–touch gestures like pull to refresh for example.
Given this book was published in 2011, decades in the fast paced world of the modern web, much of the insight rings true today.
”I’ll give you a quick recap: mobile is growing like crazy. (Really technical, I know).“
Today the difference is that everything is faster, with higher resolution, has access to geolocation and the compass, plays video with ease and touch interactions are browser enabled. There is much less separating the world of the native app to that of the web app.
The one thing that remains the same though is the screen size. Even with the advent of the retina display you are still talking about 320 pixels of width and 44 pixels still being a good size touch target.
So the real estate issue is the same, the only difference is the clarity of the image.
So on your next design or redesign where you are thinking about going responsive I encourage you to pick up this book and consider trimming the fat. Your users will love you for it, if you can convince your stakeholders to kill their darlings.
Have you read this book? Do you agree or disagree with my take on it? Have you read anything else that has influenced your design of web apps or sites?
If so I would love to hear from you in the comments.
