Websites: just a bunch of pages, right? No.

I’ve been creating websites for a while.  Big deal, right?  Everyone and their mother can say that in 2013.    It’s easy, right?   Just draw a set of pages on a white board and connect them and then fire up whatever tool you use and throw these things together to make a web site.    It’s such an easy bikeshed to set up, and everyone wants to be involved with drawing diagrams of pages on a white board and connecting them together using terms like, “Dynamic” and “Javascript” without having to sit down and bang out the code themselves.

Everyone fashions themselves a Jakob Nielsen these days, and everyone’s always ready to tell you that you “got the structure of the site wrong.”  This is the way people do it these days, and I’ve been in these meetings.     These interminable meetings with executives spouting off about what colors they like and whether buttons should be rounded.

“It’s just a bunch of pages, right?”

@#$@ no.   Cut it out.    That’s the way you might create a web site for the local chocolate shop or maybe the 100 sq ft. Irish sweater store on Main St.   But, a company’s web site.  No.

No no no.

Pages are what you should think about last, and high level executives… Dude, how about you figure out what the company does first before you dive into HTML structure?   No one does this, it’s crazy making, almost every web site I’ve been involved in is run like a cargo cult.   (Look at how they do it, let’s do it like that because it’ll bring the customers over.)

Don’t start with “pages”, start by figuring out a good reason to have a web site…

This is the missing piece.  Right, the starting gate for creating a website is in the wrong place.  Don’t start with nav menus and discussing color schemes.   I don’t care where you work, you could work at Google, but the default answer to the question: “Do we need a website?” Should be no.

Start with the assumption that you don’t need a website, and convince yourself objectively that you do.  Make a game out of it.   For most of you this will be an easy argument to make.   But, you should be forced to make the argument, and in doing so it should focus the effort on the real motivations for having a web site.

You could be making a website for a company like Forbes.  Of course you need a damn website at Forbes, but go through motions and write up a set of justifications.  You also should be open to the idea that you might not need a website, I can think of several local mom and pop restaurants around here that don’t need a web site; in fact, they have websites that probably detract from business – they could just use Facebook or GrubHub.

Nope, don’t start designing yet, you have more thinking to do…

Start with any of the following:

  1. Figure out who your audience is.
  2. Then ask yourself, why the @#%# do we want a web site?   Answer that question, don’t just do it because everyone has a website.
  3. Figure out what you want your audience to do?  Do you want them to buy something?  Do you want them to learn something?
  4. Now, here’s the important part, put yourself in the mind of audience member and figure out what would make you do #3.

Only after you’ve figured out the items in that list should you take the cap off of a dry erase marker and start drawing anything on a whiteboard.  And, really at that point, don’t start talking about pages and navigation and all the bull5#$! that people normally associate with web sites.

You’ve got the Why and the Who figure out?  Now think about what you do.

Instead, start thinking about this:

  1. What is it that you do? Or sell? Or teach?  Whatever.  What do you do?
  2. Model that.   I know this is tough to do for most people, but model the things you produce or write or whatever.
  3. Think about the user’s decision making process in relation to whatever it is you just figured out in Step #2.

Maybe.  Maybe then you should talk to someone about a website, but don’t rush it.  

And, don’t skip all the stuff I just told you to do, this is how “Design Firms” and “Marketing Specialists” screw companies out of a ridiculous amount of money.   They sell them this idea that it’s easy to just make a website, they skip all the important conceptual work that needs to be done, and just dive into selling time and services for all of this.  Then they circle back and realize that it takes far more time to retrofit a purpose for existing on a website that is done and you get stuck with a marketing firm that wants to help “position your business.”

What I’m Saying: Position Your Own Damn Business

Figure out the reasons and the audience before you start talking to that guy with the shiny shirt, thick dark rimmed glasses, and a $200/hour rate.  Figure this stuff out before someone fires up an IDE and spits out a Rails site, installs Drupal, or, worse yet, spends $5 million on an expensive (and unnecessary) enterprise content management system.


Recent IM Conversation about Rapidweaver

Courtesy of XKCD

  • ME: Hmm, you don’t the tool doesn’t support anything like that
  • ME: I’m essentially going to hand craft the theme we’ve already made to do this
  • ME: Rapidweaver is the kind of tool that you approach with an idea of how it should work
  • ME: It quickly fails to meet your expectation and then you have to figure out what it is all about
  • ME: It is somewhat counterintuitive in that, it allows you to create a web site, but it doesn’t really allow you complete control like Dreamweaver
  • ME: It is a “Now you are playing by my rules” sort of tool that demands you submit your will to it entirely
  • OTHER: i… will… submit…
  • ME: resistance is futile
  • OTHER: so, if you send us a sandwich, and we do some edits, can we publish it back at any time? or do we need to coordinate with you guys to make sure we’re not blowing away something you’ve done in the meantime?
  • ME: Right, for now, I’d recommend just sending me text… in an email
  • OTHER: ok
  • ME: Passing sandwiches back and forth will work but only when we coordinate timing
  • OTHER: ok, we’ll be careful
  • ME: Like, “You’ve got the sandwich today!”. You, “Ok, I am the master of the sandwich”. Me, “I won’t modify my sandwich”, etc.

Unrealistic Expectations: AJAX

Sometimes people approach a tool like Rails with a set of expectations like “Rails is for AJAX”. Someone might helpfully suggest that they take a look at Rails because it makes AJAX very easy. What you don’t expect is for someone to come back in a few weeks, with the understanding that Rails is the appropriate framework for implementing a set of Rich component widgets ala Flex. With custom helpers for managing pages with hundreds of ids, and expectations that you are going to have custom slider widgets that manage the dynamic scrolling and insertion of elements in a UL. It just makes for some very heavy browsing, AJAX is a great thing, but its overuse is the reason why my browsers are feasting on memory.

I’ve seen it. Someone gets the idea that Rails is some sort of rich GUI framework, and then they are perplexed to find out that any web technology that requires 20 server callbacks to load a page just isn’t “scalable”. It’s unfortunate when it happens because it simply provides fuel for people who said it wasn’t going to work in the first place.

If you need richness, go with Flex. Flex isn’t rocket science, trying to create the same level of richness in AJAX is rocket science.

Adding a Reference to a CSS or Javascript Page in Wicket 2.0

Assume that you were developing a site in Wicket that made heavy use of both the Protoype and the Scriptaculous libraries. Sometimes you’ll be using Prototype scripts directly in your HTML files, and at other times, you’ll be using prepackaged functionality like wicket-contrib-scriptaculous. You want to add a reference to the Prototype and Scriptaculous scripts to every single page on your site, how would you do that?

Page Inheritance
When you create a Wicket application you usually make liberal use of inheritance to give every page in your application a common set of components. You may also make use of abstract Section pages which are the super classe for every page in a given section. These section pages would take care of adding common sectional navigation and the top-most page would be responsible for setting up all common elemenets. Since Prototype and Scriptaculous are going to be universal elements, you will add IHeaderContributors somewhere in the AppPage class from the diagram below:

From the diagram: your application extends Wicket’s WebPage class with an AppPage class. This AppPage class adds a universal border to all pages on the site. A concrete HomePage class extends the AppPage class and, lastly, there are two sections (A and B) which each maintain a separate abtract section class to add section-specific navigation and components.

Where do we Add Prototype and Scriptaculous?
If you were going to add a reference to prototype.js and scriptaculous.js, you would do so in one of two places. A.) In the section of the AppPage.html. OR, B.) In the constructor of the class. Let’s look at both options. Adding these references to the constructor of AppPage means that the references will be available to every page which extends AppPage.

Adding a Reference to the AppPage.html

If you were going to add a reference to the AppPage.html file, you would add the following:

<script type=”text/javascript” src=”resource/js/prototype.js”></script>

In this scenario, you will need to make sure that “prototype.js” is available under the resource/js/prototype.js path in the web application. Wicket will take care of prepending the content path to this reference.

Adding a Reference to the AppPage Class
To add a reference to the AppPage class, add some HeaderContributors. A HeaderContriburor is an implementation of IBehavior and can be added with the add() command

public AppPage() {
new AppBorder(this, “border”);
new FeedbackPanel(this, “status”);

add( HeaderContributor.forJavaScript(ScriptaculousAjaxHandler.class,”prototype.js”) );
add( HeaderContributor.forJavaScript(ScriptaculousAjaxHandler.class,”scriptaculous.js”) );

There are two convenience methods provided by HeaderContributor – forJavascript and forCss. Boh functions take a Class and the name of a resource. When using this method, the Javascript resources is stored on the classpath as a resource in the same package as the ScriptaculousAjaxHandler. The ScriptaculousAjaxHandler is a class that is bundled with wicket-contrib-scriptaculous.

Fed Up with Java Web Applications

Java is quite possibly the worst technology choice for a web application. I’m growing tired of the constant need to kill server / compile / restart server. Maybe it is the fact that I’m being forced to use Resin? Maybe not. But, in general, Ruby on Rails is appearing more and more enticing the more I use Basecamp.

Do I still see relevance in Java? Sure, but I’m starting to grow tired of Servlet 2.4 and JSP 2.0. Sure, the world could easily evolve a more straightforward alternative like Groovy or Jython, but these two technologies seem very derivative. What is it that I’m looking for? Not having to wait between ideation, implementation, and testing. Without the fancy words: I’m sick of having to restart my servlet container, or wait for my code to compile just to add a Date object to my request. Page compilation, configuration nastiness, trying to ensure that one of my 12 XML configuration files for Resin, Hibernate, or Spring isn’t screwed up…..this all adds up to an incredibly inefficient work day (early morning).

These problems are not specific to Java, as much as they are just symptomatic of “Enterprise Application Development”. Java is good for problems it was meant to solve, but creating an agile user interface just wasn’t one of them.