UI

Designer v Developer Death Match

There’s been some interesting buzz going around about the role of designers and developers in the modern web development process. The demi-gods at 37Signals sparked some controversy when they posted about why they skip photoshop. Andy Rutledge posted an entry on his Design View blog about how to be an employable designer. James Bennett summed everything up nicely with his Designers and Developers: FIGHT! entry.

I’m surprised (and not at the same time) from the reaction from both designers and developers. Both want to keep their “I know something you don’t know” status while insisting that their jobs and skills are important. However, once we inject some professionalism into the debate it becomes clear why combining talents is the best scenario.

The Geek Ethos and Jock Revenge

Part of the greater geek ethos is that you’re a superior being who has used your talents to amass an amazing amount of knowledge and skill in a particular field. You step on those ignorant fools who can’t normalize a database or implement a design pattern. You have sacrificed your time and energy (and encounters with the opposite sex) to get to this level and Linus willing you will not have some pesky designer approaching your level of geekliness.

There is something about your average programmer, developer, dba and general nerd that gives them an inferiority complex where knowledge of a subject and skills in a work environment are treated like a zero sum game, “you cannot has mai skeels!”.

Study the Basics, Master Their Use

In the modern web development work flow, the best results occur when designers and developers work side by side to produce the end result. If the separation between the two is too great, there will be an obvious disconnect between the design of the finished product and the development of the finished product. Like a puzzle missing some pieces.

To achieve this melding of talents both designer and developer need to go beyond their comfort zones and learn something new from one another.

Designers

Learn basic HTML
Learn basic CSS styling and layout concepts
Learn how your developer’s program interacts with your design (the V in MVC)
Learn the basic concepts of your developer’s programming language

Developers

Learn the basics of information architecture, usability and visual hierarchy
Learn the basics of spacing, margins and padding for elements on the page
Learn how to use white space
Learn the basics of design (line, type, shape, contrast, texture etc.)

Ignoring Ego for Fun and Profit

If designers and developers can get past their own desire to be the most important person in the process and realize that their own personal short comings are what matter, the world of web development will be a better place. You will be amazed at how successful you are when you’re on the same page as your designer. It’s not enough to complain that the other person doesn’t know what you do and that they don’t respect your skills, drink your own medicine and learn what you don’t know if you want to become a better piece of the puzzle.

Who Needs The Show Action Anyway

We all know that Rails has seven standard REST actions, index, show, new, create, edit, update and delete. Usually there are only views associated with four of them, index, show, new and edit with new and edit usually being the same. This all makes perfect sense for the public facing part of the application, but what about the administration portion of your app? Do you really need that show action? Are you going to be displaying the information in the same way as the public facing side of things? I’m starting to think that skipping the show action in the administration portion of the application is not a bad idea.

Context Is Key

One thing that I’ve noticed with your average “show” action in the administration portion of the web app is that it ignores the context in which the administrator wants to see the data. Rather than displaying what the public user will see, the admin show action is usually just a basic display of the information from the record.

For example, say you’ve got a content page that you have the ability to edit through the administration area. When you’re done editing it, you want to check the formatting, colors, links and general look of the page. Unless you’re using the same CSS styles and layouts for the public facing portion of the site and the administration portion of the site, you’re not going to be able to get a good idea of what it’s really going to look like. Sure you could recreate the public facing styles and part of the layout in the administration area but that’s jumping through a lot of hoops and getting out of DRY land.

If the information that you’re displaying isn’t view/layout dependent (like a user record) then there is probably no harm in having a simple show view that looks different in the administration area and the public facing area. However, if the information ends up being styled and displayed differently between the two areas, it might be worth for going the show action in the administration area.

How Rails Can Help

You’ve decided that it’s important to always view the public facing version of a resources show action when you’re in the administration area, luckily Rails makes it pretty easy to implement this functionality.

1. Add a new member route to your existing resource

  map.resources :pages, :member => { :preview => :get }

2. Add the new preview action to your controller

  class PagesController < ApplicationController
 
    # ...
 
    def preview
      @page = Page.find(params[:id])
    end
 
    # ...

3. Tell your action which layout to use

  class PagesController < ApplicationController
 
    # ...
 
    def preview
      @page = Page.find(params[:id])
      render :action => "pages/show", :layout => "public"
    end
 
    # ...

4. Add your new “Preview” link somewhere in your Administration area

1 2	# show.html.erb in app/views/admin/pages/show.html.erb <%= link_to("Preview", preview_page_url(@page), :target => "_blank") %>

This assumes that you’ve got the public facing show template in app/views/pages/show and a layout file named “public”.

Now you can edit your records in the administration area but view them in the context that makes the most sense. While I might not do this to something like a user record or order receipt, this is definitely a good idea for blog posts, content pages and other administrable content.