So I gave it a try….my verdict? Won’t do it again….

Now this is no criticism of the company that does it, because they are good at what they do and serve a purpose. The only problem is that their purpose is not my purpose Its a good solution if you are not intending to work with the templates they provide, and possibly just use it for a static website.

Problem is that they don’t think of their CSS in a way that is re-usable, they create CSS styles for absolutely everything and don’t think about optimising the CSS for re-use across pages. The end result is that your XHTML is nice and concise, but the CSS is very verbose and long (100’s of lines).

I have ended up using their XHTML and re-creating most of the CSS so that I can re-use it in my application as a template. I am still going through this process and therefore, something that would have taken me a few days to do (create XHTML/CSS from Design), is still taking me a few days to do, but I have the added complexity of working with code that was written by someone else.

Oh well, a lesson learned

ho hum…………………..BORING!!!!

This is one of those urban myths that seems to never go away. People are always trying to stumble on that next killer idea. But the thing is, you and I probably have these great “wouldn’t it be awesome if…..” ideas almost every second day. And so does everyone. Since I am in the business of making ideas come to reality, I get my share of friends (also known as nut cases that think I am waiting for them to bombard me with their next great idea) calling me with their idea and are surprised by the fact that I don’t drop everything to work with them !?!?

So if this is not important, what is?

Your Customer!!! Its that simple…

Its much easier to fill an existing void for your customer than it is to convince your customer that they are in need of this fabulous invention. And timing is key, if you get it out too early, there will be no demand (you are trying to convince them they need it); too late and you have missed the market (someone else has beat you to it and your customers already have the product).

Its also important to extract the idea into reality. How much will it cost to build and distribute. “I can get it into every household in the country over the next 5 years!!!”, but when you do the numbers, the revenue you make never catches up to the cost of marketing and distribution (or maybe in 20 years it does) #FAIL.

You need to get ‘real’ customers in front of your product; get feedback, evolve, refine, more experimentation and testing, and work on filling that need.

Although this was always part of my 2009 plans, they never eventuated Mainly because “paid work comes first”. I think that is a problem we all encounter when we want to work on our own pet projects. We have best intentions, but we get caught up with commercial deadlines from other customer (paying customers) and these take precedent.

And what happens is “another year goes by” and we don’t realise that its another year where we haven’t achieved or even worked on our dreams. Its4aCause is a project that I have now been working on for 18 months. I have gone little further than the initial planning.

So 2010 is the year!!! Time to make a change (sounds like a Michael Jackson song), but I have decided to make sure I prioritise my own projects in the same vein as paid projects – no exceptions!

I have decided that I am going to dedicate one day a week to my project. It may be broken out over several nights/days, but I want to at least dedicate a good 8-12 hours (at least) to my project. You may think that is not enough, and it probably isn’t, but the main thing that I want to ensure is that there is momentum. Bottom line is that 8 hours a week is 416 hours in the year, or equivalent to 10 full working weeks!!!! I didn’t do anything near that last year.

The key here is momentum, losing it means that a week goes by, a month goes by and finally the year goes by and nothing has been achieved. Like a freight train with a full load, it goes slow, but it eventually gets there!

Basically the idea was a bunch of developers, business guys and designers got together and delivered a startup, from start to finish in 24 hours. And I mean START to FINISH! They get together and don’t even have an idea, take it through to the point that on the 24th hour they launch the site live. The launch included a blog, twitter account and facebook page. “I love it when a plan comes together”

Then if that was not enough, they then list the startup on eBay and within 7 days get $5,100 for it. Not bad for a day’s work (sure, a long day and they have to split amongst a dozen of them)!

It reminds me of all the developer camps that go on, but I love the energy of this and how they deliver it.

Its a real inspirational story, and makes me want to lock myself in a room for a weekend to see what I could achieve!!!

Check ou their final product http://www.drhue.com – a shop-by-colour website

After going around in circles within this legal for some time now, I have managed to start getting a positive result. With the help of the Philip Argy (@philipargy) I have now hooked up with the team at Optim Legal. We had our first meeting last Friday, and it was great to chat with like-minded individuals!

They seem to understand what I am trying to do, and how I am trying to do it!

I really am after three things from my engagement with them;

1. Advice whether there are any gaping holes in the Business Model
2. Advice on how the whole thing needs to be structured correctly (legally and from a business perspective)
3. And finally, help with the Terms and Conditions for the site

I anticipate that they will get back to me in the next few days with a plan of attack and I do look forward to working with the team at Optim legal, they really are a breath of fresh air in the legal world!!!

Recently I have been toying with a small change to my business model. Although it is a small material change in regards to the technical implementation of one of the features, but there is a significant effect of how potential users would interact with the site. I have thinking about this for the last few weeks and I can’t find a clear benefit (or detriment) to either approach.

So today over lunch with my good buddy my best mate Joe from EmediaCreative (today is my birthday by the way ), he mentioned the idea of a Focus Group. I had thought of this before, but I thought as a one man show, how can I manage (or afford) to do this? But Joe mentioned something quite important “Between us, I am sure we could muster a dozen friends to sit down and do this with”. And he is right!!

But I then thought, why stop there? Why not work the social sphere. Time to mention it to people on twitter, followers to this blog etc etc! These random people are going to be more impartial than my friends that might be afraid to offend me.

So the offer is going out; Want to be part of a focus group for an exciting new start-up? Complete the form below!!!

Essentially the concept is that you work from the user’s perspective down, rather than thinking through the requirements to come up with the domain model, class models and the like. The reason that this is beneficial is that you focus on what the user actually requires to do, not what the system expects them to do. And that is the first step towards building systems that employ best practices in usability. There are many methods and practices that are already used from a ‘technical’ perspective (such as Behavior Driven Development), but I try to look at this as a holistic development approach.

I have gone to some extent to try and formalize this approach and it is something that I am using in the development of the Its4aCause web site. I have broken this into essentially 9 (quite detailed) steps of the project. They are;

1. Concept

The concept is the start of the project. This is your elevator pitch, twit-pitch or the ‘back of napkin” concept that you capture. Do not omit this! It is actually the pure idea that you initially conceive and you should constantly come back and validate it. You will need to evolve this into some kind of 1-pager that you can use as your ‘brochure’ whilst working on the project.

I personally like writing a concept paper that is no longer than 2-3 pages with pretty pictures. This is something that you can share quite easily to make sure that anyone that reads it, gets your idea. It describes the concept, the user experience, the benefits for all involved and finally the business model. This document (and your concept in general) may change over time, but make sure you validate this as you go. Only change it if you feel it SHOULD change, not because something in your project has changed and you are ‘forced’ to change this. This should set off warning bells.

2. Brainstorming

Brainstorming is also an important step in the process. We all do it, and we do it at different levels of detail.  We work through our idea (“concept”) and start working through the details. When building software, there are two important qualities that you must identify in your brainstorming session;

a) Is there a Business Model? – Is there an actual model that is worthwhile doing? Start thinking through the detail of the execution, and if the idea is going to be valid and ‘doable’. Many a time, the whole thing will fall over when trying to work out how to do it, or how it will make money. You may find out that your idea may not be economical to execute, or the technology doesn’t exist or is too expensive. Brainstorming is the time to identify this.

b) Know what you don’t know – During brainstorming, you are trying to fill in the details. But its the gaps that are more important. And that is what you REALLY should take away from your brainstorming. That means identifying, that you “Know what you don’t know”. What is it? Well, by not identifying these items, you are entering the whole thing blindly. You handle these items by identifying what you don’t know, and how you will resolve it. For example; “We don’t know how this application is going to scale, we need to consult with someone that has worked on high transaction systems” or “We are unsure what the business structure is going to be, we need to discuss this with a lawyer or accountant.”

3. Paper Wireframes

See how we have jumped straight to our screens? We are not talking about the database design or the technology, we are talking about what the user will use. That is because we will be building the whole application from the Top-Down. Paper wireframes can be exactly that, where you start scribbling screens out onto paper or whiteboards, my preference is to prototype user interfaces using products such as the great OmniGraffle on the Mac. The important part of Paper wireframes is that you a) focus on the user experience, b) focus on what is important, c) determine the interactivity within the application & d) Test your application in the early stages. It is beneficial to do this with Paper wireframes so that you are not distracting the application with “Design”. That should come next.

One thing that I would like to add, is that I do practice a type of Agile methodology over the top of this. I am not strict with Agile (can’t exactly pair program on my own), but I definitely like to capture my User Stories in a tool. Sometimes that tool is an Excel document, but I recently purchased a copy of Jira and am using that. I generally build up my stories and think about a release schedule on what I need, but I find that my wireframes (and sometimes as early as my brainstorming session) I can start putting the stories together that I will need to deliver.

Additionally, you would have seen in a previous blog post that I like writing scenarios. Scenarios are creative writing pieces that describe the application. They are the commentary that accompany the wireframes. In many instances, I will build my wireframes to satisfy my scenario. The Scenario is usually something that is written during the brainstorming and wireframe process.

4. UI Design “look & feel”

In many ways there is no reason that you can’t work on this in parallel with the wireframe design. This is when you start focusing on the main screens of your application and the User Interface. Remember its a Top Down approach, so the UI is important in the early stages. Along with the Wireframes, this will communicate what the end application is going to be. At this stage, you need to focus on what the main pages in your application are – the ones that are going to be used the most. There shouldn’t be more than 2-5 of them in your initial pass. Aim to get these right.

After you have your wireframes and your main UI, its time to look back at your concept and make sure that you are still on track!! Have you lost the plot or are you still focused on your initial goals and is it all still valid?

5. HTML Screens

After you have the layout of your design and application wireframes, it is time to start working on the screens as they will be implemented. That means starting to decide on CSS frameworks you may use as well as Ajax frameworks as well. This may change, but it is certainly less work later if you can make a commitment now.

Try and build the whole web site in HTML, simulate as much of the Interaction and links as you can, but don’t start building stuff that you will throw away. A  good example, is don’t start building Ajax interactivity where lots of it will be generated by your App framework.

This is a great step in your project because you start seeing what the final result is going to look like.

6. UI/Controller Layer (Stubbed Actions)

Now we start REALLY building! After you have your HTML screens its time to start wiring it into your application framework. And this is another reason why I love the GRAILS framework so much. It is soooo easy to do this. The process I go through is to go ahead and create the application “grails create-app”, and then I think about the controllers I need. Usually, I will (at least) create one controller per main menu item (rule of thumb), and use Marc Palmer’s brilliant Navigation plugin to create my navigation menu. I will write a separate post on this whole process for Its4aCause, but the useful thing is by the time you get to this stage, you are actually creating the application that you can navigate.

7. Tests & Stubbed Service Layer

This is when I start adopting some TDD (Test Driven Development) practices. Nothing very different here, although I have a UI! In fact my UI is probably 90% complete now (minus anything specific that the App will generate – try to keep this to a minimum to help maintain your application). I start stepping through my application (the stubbed one that I created in earlier steps) and start writing the actual functional code. I do this first by writing my tests, ensure they fail, and then write the code that make them pass.

The tests should be driven by the User Interface that has been designed, the stories I wrote in Jira, as well as the Scenarios that were written during Steps 2&3. Remembering that your scenarios will never be the complete product, but the pre-alpha should demonstrate the scenario that ’should’ be discussing the most critical parts of the application.

I mention a “Stubbed Service Layer” in the title, because this ensures that I stick to the disciplines of passing business logic off to my Service layer rather than writing it within the Actions of my Controller layer. At this stage I decide what needs to be a Service, create that service and stub the expected behavior there. Remember to plaster //TODOs everywhere to make sure you don’t forget about any of these

8. Service Implementation & Data Layer

Wow, Step 8 of a 9 Step methodology and we haven’t written any functional actual code yet!!! WTF! Well, in reality, you should now be 80% there and the code you write should be straight forward. Now you start building up your data layer and create the domain objects and start implementing the Service layer. Don’t get me wrong, you are not going to write all the tests for your application and then the implementation in this step. Steps 7,8 & 9 are actually an iterative process that you would expect to do in a typical Agile fashion.

I do this by planning my current iteration in Jira, and map out the stories that I am going to work on. I then go ahead and write the tests for that first story, and then the services, I then stub the services, and finally write the code. OK, I just said something controversial “Stub  the services” Most people want their tests to fail, before actual code is written, and I do to. But I will also make sure that I know what has to happen to make the tests pass too.

9. Utility Classes

Finally, this is the cleanup. Time for some heavy refactoring. Although I am giving this phase the title of “Utility Classes” it is time for a general clean up. This happens as you go, but you start to find better ways of doing things, or ways to optimize your application, or remove repetitive code.

Conclusion

So what is the benefit of all this? Well, you would expect to have cleaner and more structured code, particularly in relation to how it interacts with your User Interface. Many of the methodologies that developers have available to them focus on the back end, particularly the data and business layers. But very little focus is spent on trying to make sense of the UI layer in the mix. This methodology fixes this. I have tried this methodology with great success in smaller projects, so lets see how it goes with Its4aCause!!!

So what’s a wireframe? A wireframe in software design (particularly web applications) are mocked up User Interfaces that emulate the key elements of the User Interface. Such as what needs to appear on the screen, roughly where to position it and understand what the focus for that screen is. The next step is to make the wireframes interactive, so when you click on a button it ‘emulates’ taking you to the next screen – these are prototypes.

Wireframes for me replace the old ‘back of a napkin’ concept, where you convey enough of an idea to be able to have a meaningful conversation without completing the vision to stifle any creative imagination the viewer needs. Wireframes serve many purposes, and below I go through some of the methods and benefits I have discovered.

Sketching the UI

I know some people like to put the wireframes together using interfaces that look like the end product. I actually like using sketch like interfaces to promote some creativity when people are viewing the interfaces. When I used to build Java Desktop apps, I would use the Napkin look and feel to try and accomplish the same thing. A sketched look actually means you don’t have to be so strict about positioning of elements or be pixel perfect. As long as you are communicating elements such as where buttons and headers appear, you are getting the message across.

Interactivity

Its important to be able to transition your Wireframes to prototypes. Prototypes are working versions of the wireframes. Why go to all the effort of designing screens if you can’t navigate between them?! Again, sketched prototypes are a powerful (and quick way) to communicate interactivity. Demonstrate the flow a user needs to go through and communicate what should be displayed when a certain button is clicked.

Focus on What’s Important

Wireframes and prototypes help you focus on what is important in the design. What should the page focus on; is it the form, the search box, some content or something altogether different? By wireframing it first, you are communicating what are the important elements on that screen. This is another benefit ’scribbled’ screens have over screens that are attempting to look like the finished product. If you don’t fill the finished design with all the elements such as add banners or images it looks, well……unfinished! Wireframes are supposed to look unfinished so placing a box with a cross through it as a place holder for an ad is perfectly fine.

Testing

In my opinion, this is the single most important benefit you get from Wireframes and Prototypes – the testing. You get to test your interface before you spend a fortune building the real thing. You can test it yourself and challenge your concepts or you can work it with a focus group. You cannot underestimate this benefit. Start testing concepts like; should this 3 screen flow be achieved through Ajax? Is it dumb to complete this form through Ajax? Is there too many screens in a sign up process? or is the main focus on the screen a Search Field, but everyone is missing it!?

Wireframe hugely benefit what is done day to day when building the application. With the Its4aCause project, after I completed the wireframes, I was able to pass them over to a designer and basically then prioritise which screens I want them to work on. And I can always come back and make changes within the wireframe and completing the interactive model before building the real screens.

This concept is part of a development model that I use called “Top Down” Development that I will be writing a blog about very soon. Also, the tools of wireframing can either make this task enjoyable or a chore. I will be discussing that in a blog soon too.