Bobby Wilson

Introduction

One of the most difficult things to do as a person who makes things (websites, art, logos, applications, bird houses) is putting your project out for the world. It is hard because it is never quite where you want it to be, and you don’t want people to think you’re a hack.

Anonymity

No one has to know that it is you who made created project x. Pseudonyms have been around forever, authors use them all the time. It’s no big deal, half the time people are more interested in the work than who actually created it. So worse comes to worse you stay anonymous.

Feedback

I think one of the best ways to improve a project is to get constructive feedback and critiques. The early you get used to receiving feedback the easier it will get. It will also help you build confidence in what you do because a lot of your feedback will be positive. It’s a great deal in my opinion, the negative feedback you use to improve your project and the positive feedback will build your confidence.

Recognition

How are people supposed to notice you if you keep everything private? The more public you are about your work the more likely you are to be recognized. It will also open a bunch of opportunities for you. You could win an award, or land your dream job. One of the reasons that I started this blog was to open up a channel into my thoughts and opinions for the public.

Outside Involvement

If you are looking for participation on your project publicly releasing it is a great way to attract fellow enthusiasts. This also ties in some of the previous topics. When your little project grows into a community driven project, you will definitely be happy to be the source of all of the recognition.

Unfinished? No problem.

Even if your project isn’t completed. You can always put it out there as something that is in “beta”, or a “work in progress”. This helps if you are stuck somewhere or don’t know which direction you want to take your project in. There are plenty of people in every industry that will be willing to give you feedback if you ask for it.

Conclusion

If you are new to something, you get it out there, and it doesn’t go as well as planned. No big deal, it will just be an indicator of progress next time you release something. Experts in their fields have tons of early work that is laughable to them now.

“An expert is a person who has made all the mistakes that can be made in a very narrow field.” — Neils Bohr

Introduction

Historically when a piece of open source software, a framework in the case of Rails is released people get fired up about using more open source software in their everyday workflow. Some may switch to Vim or Emacs, others install Linux. This hasn’t been the same for Rails, Rails developers bought expensive Apple hardware, and picked up a commercial text editor. What gives?

Apple Hardware

Most people I know that are Rails developers work on a MacBook Pro. All of the user groups, training classes, and meet-ups I have been to people sport Apple hardware. Most also carry an iPhone (myself included, it has been totally crappy lately). I know that Apple hardware just recently started to get popular since OS X came out, but this isn’t just the normal popularizing of a new technology this is something deeper. Go to a PHP, Perl, web design, or internet users groups, and you won’t see near the saturation of Macs. There is something about the Rails way and the Apple way that goes together. I think that Rails people find Rails because they want something that is elegant, powerful, and doesn’t make you mess with the low level things you don’t want to mess with. I think people like Apple for the same reasons.

My Apple Experience

I jumped on the Apple bandwagon back in 2004 when I was going to school for photography and web design. I was using Photoshop, Illustrator, After Effects, and Flash, and they all seem to run much more stable on the schools high powered Macs. So I bought a 17″ Powerbook, and I loved it, it was solid and I didn’t have to restart it all the time. The OS X interface was leaps and bounds better than Windows XP. Apple does something with their human interfaces that is second to none in my opinion. I now have a little MacBook that I bought in 2006, and it has been really great for the most part. The only thing that sucks about it is the discoloring of the plastic below the keyboard on either side of the touch pad, some plastic also cracked but I am hard on stuff and don’t blame Apple for that. Apple usually makes a good product and I can’t deny that.

TextMate

In the first Rails screen casts that were produced, there was a text editor that was being used that seemed amazing. Code just seemed to stream onto the screen. Snippets here, and code completion, a basic blog was finished in 15 minutes. I couldn’t believe it, I needed TextMate, I don’t know how I did anything without it. TextMate is many developer’s dream editor, there is a bundle for just about every programming language, and markup out there. A bundle has code completion, and snippets for whatever sort of developing you may be doing. The Rails bundle is very robust, and a lot of very savvy Rails developers use it. It definitely embraces the Apple/Rails style of simple yet powerful. If you think Rails and Apple go together, well consider Rails/Apple/TextMate the holy grail. The only catch is that TextMate isn’t open-source, and it isn’t free either. If you don’t have a Mac forget about it. To many that doesn’t matter, it has been starting to wear on me.

My TextMate Experience

I come from a design background, and I was very used to the IDE packages that Adobe formerly Macromedia put out, namely Dreamweaver and the Flash IDE. If you read my last post, I’ve since changed my mind about that. I started using TextMate and thought it was the be all, end all of editors. I was using the code completion, and getting a handle on snippets. It was great, until I got hired at a company that uses all PCs (except for Chris). I did manage to get Linux on my box, but TextMate was not happening. No Mac no TextMate. I am web developer, I need a text editor, and I am not going to use a different editor at work and at home. Exit TextMate.

My Open Source Experience

I have always been a fan of open-source software because it didn’t cost anything, and there was always a community that would give you a hand in getting going. I would take an open-source community over commercial customer support any day. Just today I was working on something that didn’t seem to work quite right, and I was able to hop into the IRC channel for the software I was using and work through the bug with the lead developer who maintains the software. It is hard to say the same for commercial products. With open-source software you become apart of something. You may start as a user, and then look for some help on a feature, the next thing you know you are the veteran helping out all of the new people using the software. You may even contribute to the source of the software eventually. This is the sort of thing you can never dream of doing with a commercial product unless you become an employee. Open-source developers are awesome because most of them work on a project because they love it and they believe in it, not because they are lining their pockets.

Conclusion

I think that most Rails folks choose what works for them and leave it at that. It doesn’t bother them that while Ruby is open-source and Rails is open-source, and their development platform isn’t. It didn’t bother me at first, but now it has started to bother me. The biggest issue is not being in control of how things are set up, and not knowing the system from ground up. This is my new goal, completely know my system from hardware details, to operating system, to software details. I am going to start looking for a good (non-Apple) hardware vendor. Any recommendations?

Introduction

If you are a developer, designer, blogger, qa analyst, manager, or copywriter; there is one tool that you should completely own. Your text editor. I think it gets overlooked and underused. We are enticed by the wide array of “productivity” enhancing tools that have more features. There is a legion of folks who believe that something as measly as a text editor can’t handle what they need in their daily workflow. I beg to differ.

Workflow

Your editor should fit nicely into your workflow. It should be able to handle any sort of ASCII file you open in it. Whether a plain text file, Ruby, Textile, HTML, CSS, whatever, you use, it should open. A developer won’t spend much time without their favorite editor open. If you are opening a file in a programming language or markup, it should highlight it. This goes beyond actual work too, text editors are great for todo lists, taking notes, the list goes on.

Advanced Features

The key to a lot of text editors is the advanced features. Advanced features may not come easy, I still struggle to introduce a new advanced feature into my workflow but it gets there eventually. Read a manual or buy a book on your editor and learn the ins and outs. The advanced features will make your life easier, and speed up your time spent editing.

Multiple Environment Support

This is one thing that has kept me from working exclusively with TextMate (and it isn’t open source). It only supports OS X and has no plans on supporting any other environment. I respect their decision, but that simply doesn’t work for me. At home I have an Apple laptop, and at work I am on a run of the mill desktop running linux with a Windows VM (for Outlook and IE testing). I have warmed up to the open source editors Vim and Emacs. I currently use Vim, but I am interested in giving Emacs a fair chance as well. There is a flavor of both of these that will run on any widely distributed OS. Which is great because I will never have to worry about my editor not being supported by the OS.

Why not an IDE?

I don’t agree with using an IDE simply because they try to provide more than what I want. Often times they include build tools, compilers, APIs, version control, and more. I prefer to manage that outside of my editor. I understand that when you get into something new you want some of the features that do things for you, but I felt like I never truly learned that stuff because I was in an IDE. Why would you learn something when you just had to click a button and it would work for you? The other thing I don’t like about these is that by the time you have all of the side-bar, bottom-bar, top menu all showing, it leaves you a very small window to edit your text with. Boo IDEs.

Conclusion

I love text editors because they are light weight, do exactly what you expect, nothing more, nothing less, and they are rock-solid stable. If you spend any time at your computer producing code, documents, lists, or blog entries, it will be worth it to you to get awesome with your editor. There is a good chance that your editor will be around for a lot longer than the language you are working with (Vi created in 1976).

Vim
Emacs

Trap #1 “Baskin Robbins”

A classic trap that I have fallen victim to is the old, “I give you the freedom to make the decision.” This really means that they don’t know enough about what you are doing to have an opinion, but when it is finished, they will tell you how they really wanted it. This is usually also means that you will be fully accountable for the route you take.

Solution #1

I think the best way to work with this situation is to go 31 flavors on them, and serve them up a baby spoonful sized portion of functionality. If they like it, continue development, if not, give them another sample size. You can make it fun too, like the little pink spoons. It doesn’t cost much to pump out the small pieces of functionality to get rapid feedback from your client. With this route they are sure to get what they want, and they become accountable for helping make the decision with you.

Trap #2 “Anthony Hopkins”

This one is like the deadfall bear trap in the move “The Edge”. Your client has just come across the most awful inspiration ever, and they want you to recreate that style or functionality. This hurts especially bad, because they are so excited about site “X” it’s exactly what they were looking for, now all you have to do is recreate it.

Solution #2

I think at this point, it is important to find out what they like about it, and why they want an exact replica. The next thing to do is to educate. If the thing that inspired them is truly horrible, criticize the elements that are horrible not the entire project. It is best to stay honest on this, or it will come back to haunt you.

Trap #3 “The Odd Couple”

In almost every facet of my life, I run into a situation where I don’t know what I want. It can be features, color palate, ice cream flavors, hairdo, should I stay or should I go. I think it happens to all of us. In terms of web development, it is a tough spot to be in when you are fulfilling a request to someone who wants something but doesn’t know quite what. Clients that aren’t web savvy will often not know what they want. Clients that are web savvy can sometimes be even worse because they know the possibilities.

Solution #3

When there is a lot of uncertainty I think it is best to keep it simple and refine the clients requirements. It is much easy to find a solution to a problem when you know what the problem is. If you and the client can’t find a problem, you are already done. With the clients that are excited about all the possibilities, tell them that it is important to start small and fulfill the base requirements. Grow with the demand.

Conclusion

These are some common scenarios that I have found myself dealing with lately. The solutions are basic, and I think your client will appreciate that. When they find out that you want to build to their requirements rather than build a bunch of stuff they don’t need I think they will be even more happy with you. Web development doesn’t always have to be complicated.

Are you serious?

Yes. Absolutely yes. Static content is the lightest, easiest, and fastest content on the web. There was a time, when I was all about the latest and greatest in CMS technology. I have spent many a hours trudging through the bowels of Joomla, Drupal, and Mambo. Slashing the foliage of MovableType, Mephisto, Typo, and Wordpress with my machete. All because I needed the most flexible, extendible, hackable, and mashable solution to manifest my off-the-cuff projects.

Why use plain ol’ static pages?

The first reason, is that static pages “just work”. Yeah, you can make typos, mismatch markup, and break links, but even with the most abstracted CMS these issues still exist. With static pages, there is no “moving parts” so to speak.

Automation

Static content doesn’t mean you have to write out every single piece of HTML by hand. In fact, there is excellent software that you can run locally to build shared layouts, generate blog entries, and leverage dynamic templating. You run a build command and the software pumps out static pages ready to upload. You can even automate the upload/syncing process.

It’s cheap!

You can sign up for the least expensive hosting package, and that will work just fine for a very long time. It’s cheap in terms of resources too, web servers (software) are usually very light weight. Storage and bandwidth will be the only variables you have to worry about. Storage is not a problem, scaling storage is easy and relatively inexpensive. Running out of bandwidth means you are transferring a lot of data, which is usually a good problem (people are visiting your site). Maintenance is minimal, you still need to call your web guy to make edits and updates, but problems will usually be simple fixes.

SEO

Static content is ideal for SEO, the search engines see everything just as it is, plain ol’ static HTML. Search engine spiders were built with static pages in mind. The spiders can quickly and easily parse through all of your pages without a hangup. In terms of SEO, nothing beats static content.

When static pages won’t cut it

Web Applications

There are plenty of situations when static pages won’t cut it. In terms of web applications you are out of luck. Even the most simple applications use some sort of dynamic technology to exist. Every form you see uses a dynamic technology to process the information. That isn’t to say that you must say goodbye to static pages. Applications can still have a large amount of static content.

What about blog?

Blogs can be pulled off with static pages, and I am still intrigued by the idea. With a static blog, you don’t get the administrative dashboard, you don’t get plugins, and you only kind of get comments. Why am I using this database driven blog software to run this site instead of generating static content locally and syncing it up? One of the few reasons that I am, in fact, using a dynamic blog engine is because of comments. There are ways to have comments without using a database, but it wasn’t compelling enough to me. I also like the web interface that lets me publish from any computer with internet access.

Conclusion

Static pages are great because they are quick and easy to create. They are ideal for sites that showcase a company or product. Some clients might ask if they will be able to edit a page, and you will tell them no. The truth in this situation is that aside from just plain body copy, a client won’t really know how to change anything else even inside a CMS. I would prefer to save the upfront hours I would spend setting up a CMS and spend them on these minor updates and changes. Static pages stay completely usable even if you do decide that you need a little more infrastructure, you just pop them in as pages in your new CMS.

Resources

Ruby static page generators

• webgen
• webby
• nanoc

Introduction

If you ask any web designer what tool they use most in their web design toolbox, most will tell you Adobe Photoshop. Web designers love Photoshop because they can use a familiar image manipulation program to create a very colorful, graphical, photo rich website comp in a day. They show the client their comp, and the client gets the idea that the website is almost done, since they can see how the finish site should look right in front of them. The client is perplexed when you tell the client there is still a lot of work to do before the site is finished. The web designer sends you a “sliced” comp and their work is done.

Problems

The problem with a sliced Photoshop document is that everything is a graphic, the body text, headers, and menus. There is never a situation where this is acceptable. Even if you are making a single page that will only be up for a limited time, you will still at minimum want your page copy to be indexed in search engines, and the flexibility to edit the copy just in case there is a typo.

Usability / Accessibility

Anyone with a disability will struggle to view your page correctly. Users won’t be able to enlarge text, and a screen-reader won’t render the image text. The image text isn’t selectable for reuse. The web site won’t feel like a website because it is all graphics.

Information Architecture

When you comp with HTML you get a very nice representation of content hierarchy. The actual content of the site will be right there in black text and you will see the page for the content, and it won’t be able to hide behind a stylized graphical comp. This is essential at this stage because it keeps the content in check.

SEO

Any well designed site should be able to have the style sheet and graphics turned off and still function very well as just HTML, after all this is how the search engine bots see it. As an exercise turn off the style sheet and graphics from a sliced Photoshop document, and open that up in a browser, how does it look? As mentioned before, search engines won’t index image copy making your site poorly indexed, or invisible to them.

Development

When Photoshop comps are used just as a starting point for the actual markup and style-sheets, very little of the Photoshop comp even ends up in the finished site. The graphics that were formerly the body text are replaced with paragraph tags and actual text. The headers are replaced with actual heading tags, and menus replaced with list tags. Having actual markup and CSS instead of a sliced up image, will make it much more flexible. If you need to to make a change to the copy, you just make a change to the copy, instead of tracking down the Photoshop document editing the text and re-exporting the page.

Solutions

HTML from the start

You can use HTML from end to end. As a developer it is much easier to work with HTML created by the designer, rather than fixing the HTML that Photoshop generated, or scraping all of the generated HTML in favor of writing your own much cleaner HTML.

Client Presentation

When the designer does show the HTML comp to the client, the client will be correct in thinking that the site is almost finished. You will also be able to post the HTML comp on the web so that your client can look at the site in an actual browser instead of looking at an image file that may or may not be the actual size of the site. The more you can show your client the site in the browser the better off you will be. They will see the site in the context of a browser instead of removed from context as a graphic. The changes they request will be easy to fulfill as HTML.

Old Workflow

1. Designer hops into Photoshop starts creating their layout and graphics
2. Designer pastes in the copy from the client, or lorem ipsum if they don’t have copy
3. Designer saves out a Photoshop document comp and shows the client
4. Designer gets back into Photoshop to make the changes the client asks for
5. Designer saves out another Photoshop document comp and shows the client the new changes
6. Client finally approves the design
7. Designer hands off sliced up Photoshop document to development team
8. Developer turns the Photoshop generated HTML into something they can actually work with
9. Developer finds a typo, and tells the design team
10. Design team gets back into Photoshop to fix the error and then re-generate their Photoshop document
11. Developer puts graphic back into HTML
12. Developer shows designer the current state of the site
13. Designer wants to know why it doesn’t exactly like the Photoshop document they gave the developer
14. Argument continues, ultimately going nowhere… Leaving the designer and developer to go back and forth for almost all design changes
15. Client is disappointed with the wait every time something needs updated

New Workflow

1. Designer starts with copy from the client, or lorem ipsum if they don’t have copy
2. Designer structures the site with HTML using the proper markup for the respective content
3. Designer shows client current state of design, and explains that this is just the information architecture of the site but thought the client should understand, and provide feedback just based on the current hierarchy
4. Designer can hand off what they have to the developer to begin doing back-end work because it is HTML already and easy to change
5. Designer begins to work in styles, images, and any client feedback thus far
6. Designer shows client current state of design with styles, images, client changes, and maybe even some of how the back-end will work since the developers have already been working on their part
7. Designer can continue to work with developers to fine tune markup and styles, because they know HTML so well now
8. Developer finds typo, and changes it right there, after all it is just text
9. Developer shows designer current state of the site, and says, “it looks exactly like your comp”
10. Designer says “Duh, I wrote that HTML“
11. Client loves the speed at which the team works

The first workflow is actually how I have worked before, no joke, it seems funny to read, but that is really the way things can go sometimes. The second workflow is pretty realistic, when your designer knows HTML and CSS very well it creates a great collaborative environment between designer and developer. It lets both parties speak the same language and should speed up your workflow a lot. Designers will no longer complain about their Photoshop comps being trashed when the developers get ahold of them, because they will be writing the exact HTML that the developers will use. You can put the design on a web server immediately since it is already HTML and give your client a view of the site in an actual browser, the way the finished product will be. This can sometimes be a bit of a jump for the client if they always see the comp as a printed out image, or in image preview software.

Conclusion

It just makes sense to use HTML from start to finish. When you start with something usable you can just build upon, and manipulate that instead of always going back to Photoshop. Designers will also become better designers because they will be using the rules and standards of the web instead of Photoshops rules and standards. They will realize their limitations from the beginning. Photoshop gives you way more options than are possible on the web, so when it is exported for the web it doesn’t look how you plan it to, and just wait until you pass it to the development team. Photoshop is great for manipulating images, creating graphics, and layouts for print. Still feel free to use it to create graphical elements for your sites, but just leave the layout and styling to HTML and CSS.

Resources

• 37signals - Why We Skip Photoshop