Understanding The Need For Servers With Mobile Apps

January 24, 2011 Leave a Comment

I was looking into different task management solutions and recently started using iProcrastinate on my Mac.  Let me say up front that I most definitely procrastinate.  I’ve been writing the same book for several years and I rarely get my taxes done on time!

iProcrastinate looks good so far.  It has the right level of functionality and the interface is intuitive enough.  I grabbed the iPhone version and proceeded to sync.  This was not so easy.  My desktop Mac is on a LAN and I had to go wireless to sync even though my iPhone was docked.  Say that again?

I soon realized though that this made sense for an application running on different devices when there is no central server.  My systems needed a direct connection to communicate and that can only be done with devices on the same network if there is no other central means to establish the connection.  I remembered that I did not have to complete a sign up process to get started, which in truth was a nice simplification.  I would either have to connect my iPhone to my LAN (not sure that is even possible) or add my Mac to the wireless.

Let’s dive into the role of servers and the whole sync issue for a bit.  For my devices, I have 3 ways to synchronize content:

File transfer – Files are transferred between the devices directly.  Launch the  iTunes application with your device connected and click the Apps tab after selecting the device.  You see all the apps sharing files with your device at the bottom of the page.

Central server – A central server synchronizes all data and files between various systems.  The master at this is DropBox.  Install DropBox and watch how changes on one device are reflected on the others.  Evernote.com is another good example.  Record a voice memo on your iPhone and then listen to it on Evernote.com.  Both of these examples use a file as the base transfer unit, but there is a lot more information being shared including accounts, meta-data, etc.

Direct sync – This is the third case best illustrated by iProcrastinate.  You don’t need iTunes or a central server.  The two devices, in my case my iPhone and desktop, set up a direct connection or socket after which information is transferred automatically. This is slightly better than straight file transfer as more than just files can be shared.  It also has benefits over a central server including no need for an account or even an outside Internet connection to sync.

My favorite approach is the central server and not just because I am a server guy.  I like to sync from anywhere whether I am in my office or traveling in Costa Rica.  I really don’t mind creating an account although I hate it when my account information is shared with another service.  A central server provides solid functionality including:

  • Centralized backup of my content
  • Support for multiple devices
  • Anytime access to my data and information
  • Security through account management

The primary reason developers don’t use a server is cost/effort.  After all, file transfer comes for free if you use that approach.  You don’t really have to do anything.  Data sync requires development time.  Once launched, however, there are no on-going costs or servers to support.  The server represents a commitment to users to keep the application running in a secure hosted environment that must be available on a regular basis if it is to have any value.

In my opinion, the server architecture is the ideal approach for supporting solutions that require data sharing and synchronization.  Server side languages and solutions are cheap enough and easy enough where a reasonable developer can develop a solution without too much effort or time.  My favorite combination right now is Ruby on Rails hosted at Rackspace.  In the end, there are other ways to support disjoint data, but none of them are as powerful and capable as a server-based solution.

Filed under Development Management, Technology & Engineering

How to Launch a New Technology Service

August 24, 2010 Leave a Comment

Software companies must stay informed of the latest trends and technologies to remain leading edge with their work.  Avantica is no different.  How do we do it?  How do we bring new technologies into our service offering efficiently?  We have 3 main phases we go through before customers are offered a service or technology.  Let’s go through them one at a time.

Step 1 — Vision

The first step for any new technology is for someone to have a vision about the benefits of the technology to the industry and the company.  Someone has to champion the topic so to speak and raise awareness of the potential.  We’re lucky that our company is loaded with early adopters and an abundance of technology geeks.  Chances are if it’s new and hot, we already know about it.  Knowing about new technology is not the same thing as having a vision or seeing the market potential however.  The visionary must be the advocate or the champion to drive interest within the organization.  Let’s look at a couple of our recent examples.

While everyone in the US was going crazy for iPhones and Android, the adoption rate for nearshore providers was a bit slower.  Our CEO recognized that mobile would be big and so would mobile as a companion for Web.  In fact, he was given an Entrepreneur of the Year award for his vision and for recognizing the potential long before others.  I am proud to say that with Ruby on Rails, I was the one who recognized the power of doing things the “Ruby-way”.  I started learning language several years ago and attended industry events like the 2008 Rails Conference in Portland, Oregon.  We’re several years into our Ruby on Rails practice and truthfully it has been very successful and continues to be one of our fastest growing market segments.

In both of these cases, we recognized not only the power of the platform but also the potential of the market.  We investigated further and determined this was a good place to focus our leading edge people.  Then, we championed the idea to start to build momentum.

Step 2 – Research

Your CEO or CTO says this is a business to be in, now what?  Simple really.  Call in the gurus!  We have these people in our company that generally serve as  architects and leads on projects, but part of their time is set aside for research and exploration.  You know the type of engineer I am talking about.  These are the people who look at a blank white board and know what to draw.  They can look over an SDK and compare to the 5 other similar ones they already know.  Truthfully, we think this is something that sets us apart from more traditional outsourcers. Our senior guys are really into technology.  It’s a hobby and a way of life in addition to a job.

Our leading edge engineers explore the new technology and validate the vision.  They study the internals and create sample products and solutions to see how the pieces fit together.  Once they are proficient, these technology leaders work to bring the rest of the organization along.  They provide links to Web sites and articles that explain all angles of the technology.  Our best engineers go so far as to develop classes like the one pictured below to teach our teams the new technology.  That person in the front is one of the aforementioned gurus by the way.  We even do internal projects for teams to learn.  For example, we did a Ruby on Rails project called RubyNearShore to implement a community site with expert exchange functionality and social networking based on Ruby on Rails.  The site was only viewed internally but served as a great project for people to work on real implementations of the language.

Step 3 – Opportunity

At some point, our research validates the technology and we have enough trained engineers to field a team.  We start marketing our new capability and looking for clients who need a product based on leading edge technology. Generally, the companies we engage with are start-ups and technology companies looking for a competitive edge.  For example, when Ruby on Rails first emerged, the attraction was speed of development and that lead many venture funders to push their new companies to launch on a new language.  Over time, the technology matures as our customer base grows and eventually we end up with a stable practice that we offer to new and existing customers.

We’ll see who in our company has the vision for that next great technology movement.  Perhaps we’re already seeing that in location-based services or maybe even high volume messaging.

Filed under Development Management

Teams Need More Than Technical Leads To Succeed

July 10, 2010 2 Comments

Managers love a good lead.  Your “go to guy”.  Your problem solver.  She can collect a random set of inputs and come back with the right thing to do even if not a single one of the inputs hinted at the true problem.

I had two calls today with different types of leads (hence the pronoun switch in the opening paragraph) and both of them impressed me with their understanding of leadership in the team context.  The goal of the lead is to get to the right answer for the tough problems using the best information and resources available.

Some leads are thought leaders.  “Let me go off and think on this one a bit.”  Other leads are researchers and consensus builders.  “Let me get with our UI developer and designer and see if we can’t find a solution.”  Still other leads are coaches, which is one of my favorite types.

I am familiar with the recruiting practices of some of the larger software companies in the valley and have noticed that several of them seem to be only recruiting leads and leadership personalities.  Some top-notch engineers slipped through the cracks because the process did not account for teams and different leadership styles.  Put another way, while I love a good lead, the best teams I have managed were great because everyone executed their role well.  Michael Jordan starting winning championships when he started passing more.

I created the follow graphic to illustrate what I mean.  Please, no jokes about this not being a pyramid though I do love a good pyramid too!

The image shows various roles on a project.  Typical challenges, issues or areas of functionality you might encounter are listed in the center.  This team might be used to develop and deploy a large-scale application in a hosted environment. Your team make-up might be different, for example, smaller development teams often have one lead/architect/data architect.

Take integration in the lower left as a good example for how this chart works.  Programming interfaces can be very detailed and time-consuming to learn. Server engineers tend to be more disciplined and focused. Also, you should use the same person who designed the integration to implement the solution to limit the learning curve to one person. You need the system admin to work on protocols and security issues. As another example, user stories often come together from a collaboration between design and development teams.

You now see the challenge if you hire only leads for your teams.  We can set aside all the comments like “too many chefs spoil a meal” or “too many chiefs and not enough Indians” if you like.  Simply put, the best people to solve problems might be those who actually prefer not to be in leadership positions.  You’ll end up with a treasure trove of people who might be really into the minutia of data or very interested in understanding how systems communicate with each other.  The best teams are filled with diversity and overlapping interests.

The lead is essential and the best ones form the foundation of a strong team.  Once you have that person, your best bet is to surround him with specialists, experts and code jockeys who all understand their role in the team dynamic well.

Filed under Development Management Tagged with , , , ,

Marketing Your Company With Short Messages

June 15, 2010 1 Comment

Getting a message out about your company is easier than ever with technology and the Internet.  This is probably not a big surprise to anyone.  If we want to get a new message out here at Avantica, we write something in our blog or post it on our Web site, and then work the social networks to spread the word.

Our top communicators each have hundreds of solid connections across facebook, LinkedIn, and other networks that we can tap.  We also use subscriptions to this blog and followers on Twitter.  Add in our contact lists and a service like Vertical Response and just like that we can reach thousands of industry people with a few clicks of a button.

Take for example the recent announcement about Open Mountain becoming part of Avantica.  Here’s how we got the word out about that:

  1. Press release on prweb.com that aggregates to thousands of sites
  2. Updates to our statuses, profiles, etc. on LinkedIn and facebook
  3. Blog post expressing our personal thoughts on the merger going out to subscribers and RSS feeds
  4. Emails and phone calls to key clients, contacts and bloggers about what we are trying to achieve together
  5. Coverage in the press about the changes.

All of this is easy to do provided you do some up front planning to get contacts and connections in place. Let me provide some tips for how you can prepare your company for the messages you need to send:

Social network upwards and out – Make connections that expand your sphere of influence in addition to recognizing the connections you already have.

Twitter, tweet and follow – Your activity should be about preparing to share information and not only about your own personal daily activities.

Use great tools – Find the best tools to measure your exposure and coverage.  Try to select the most effective tools and not just the ones you find easiest to use.

In the end, the major challenge we faced was the length of the message.  People have grown accustomed to shorter more precise messages.  Twitter’s 140 character limit is tough when you are trying to cover all the reasons why you merged.  Recent studies have shown that a significant number of people get their news just reading the headlines of posts without bothering to click the link for content.

Hemingway boasted he could write a complete story in just six words.  His story was simple: For sale: baby shoes, never worn. Pretty effective, don’t you think?  Plot.  Drama.  A compelling tragedy in just 6 words.  What am I complaining about?  In fact, there are quite a few contests spawned from this story like this contest on Wired.  My favorite in here is: Epitaph: He shouldn’t have fed it. That one cracks me up!

In the spirit of “Papa”, I thought I would take a shot at reducing our core message down to just 6 words.  You tell me if you think this is effective or not.  Here you go:

Launch.  On Time.  Money left over.

What do you think?

Filed under Development Management

An Honest Discussion About Windows of Opportunity

March 31, 2010 Leave a Comment

I originally wrote this post in May of 2009.  We couldn’t post it then and risk revealing the launch plans of some of our clients.  Our end of year projects helped validate the post so we decided to publish it now.

We were seeing a new wave of companies ramping up to release in the fall as with previous years.  This was just one of many signs that we felt the US economy was turning around.  Money was flowing, new projects were getting some funding, and development teams were being staffed.

As usual, most companies targeted October listing a window of opportunity as the driving factor.  I first referred to this phenomenon in my post about the 2-month launch.

We have had many customers successfully hit October.  One company launched and closed an impressive round of funding shortly thereafter.  Another signed up a Fortune 500 company before the end of the year.  We are very proud of what these budding enterprises achieved.  What’s the one thing that has not happened?

Not a single one has seen any validation that a window of opportunity really existed.

Opportunity?  Yes, definitely.  A window?  One that might close soon?  In my opinion, absolutely not.  The opportunity available to these companies is no better or worse before or after their launch.  The proverbial window remains open for everyone even to this day.

Defining a market window is like trying to predict when the recession you are in began.  Was the Internet search market opened by the invention of the Web or the rise of Yahoo?  If Google closed that window, how do you explain bing? The iPod entered a crowded MP3 market.  facebook is clobbering myspace who left friendster in the dust.  The list goes on and on.

I was reading an essay by William Gates Sr. about his son Bill.  He said Bill left Harvard before graduating to create software for the Altair 8088 because, and I quote, “to take advantage of a window of opportunity he believed would be long gone by the time he graduated”.  This is like seeing a Model T and thinking if you don’t get into the car business soon you’ll miss out.  Laughable now, but I am sure those early companies felt this way just as Gates did and most start-ups do.

I am not saying that windows of opportunity are a complete myth.  Did everyone think Twitter would become this huge or that there was a market for really short messages?  One of our start-ups truly has a unique opportunity.  They can point to market factors, new legislation and a host of other factors converging on what truly looks like a new opportunity.

Hitting a specific window of opportunity is not the dominant factor that determines who survives in my opinion.  New opportunities open up all the time.  Eventually markets become crowded and finding success becomes more difficult.  Companies need to focus more on obtaining an impenetrable position instead of nailing the start or end of a window.

What do I conclude from all of this?

1) Running a start-up successfully is a marathon not a sprint.  Having the early lead in a marathon doesn’t matter that much. Just ask Yahoo or friendster.  You still could easily lose to runners managing their race better if you don’t do the same.

2) Windows of opportunity are very real, yet they don’t exist just because you want to launch in October.  Base your launch time on smart planning and not only on hoping to capture the big spending months before the holidays.

3) If the TechCrunch post about you lists competitors already up and running, then your product is probably not going to create a new window.  Your first mover advantage is already gone.  Learn as much as you can from your competitors.  Most importantly, don’t assume they are standing still.

Here are some different launch goals to consider along with the date of your launch:

Considering launching off-season.  This allows you to fine tune your offering and your infrastructure.  When you expect your most explosive growth, would you rather have a new product that you are still vetting or a proven solution supported by well-trained people?  Maybe ask potential customers this question?

Consider launching based on milestones instead of dates.  For example, launch after you have 500 active beta customers on the system for 2 months or more. Do you think potential investors will care about October if you can show your product is “sticky” for users?  Maybe ask potential investors this question?

Consider launching based on your financial goals.  Your product must be in the market generating revenue at a certain rate to hit your break even target.  Managing to cash flow positive is something many companies may have to do in this changed economy if you believe our predictions back in 2009. Maybe ask your executive staff this question?

I realize that windows of opportunity are one of the many motivators that drive teams to achieve the insane.  Gates may have been wrong about the market for Altair software, but his drive on that opportunity and all the ones that followed ultimately lead to his success.   Believe me, whatever the reason, you must have this drive.  Just remember that while October may seem important, surviving long beyond October is definitely important.

Filed under Development Management Tagged with , , , ,

An Honest Discussion About Adding Features Late

March 16, 2010 1 Comment

Let’s have a good honest discussion about adding in features late.  I don’t mean late like the schedule is already set and this may or may not have impacts.  I mean late like the release is just around the corner and are you crazy!  If you work at a start-up, then yes, you might actually be crazy.

The problem with adding features late is that there never is a guarantee the feature will work out.  A last minute change could make the release and get you on TechCrunch.  Or you could put in something that doesn’t matter only to find you broke something that does.  Release management is a guessing game simply because companies never have enough time and resources to test everything a user might do.

Repeat after me.  It’s always a judgment call.  It’s always a judgment call.

We use software development processes to manage decisions like this.  Two of the most dominant development philosophies in use today are Agile Development and SCRUM though some people incorrectly think they are one in the same.  In fact, there is even a book called “Agile Development with SCRUM”.  However, there is one interesting difference in the foundation of these two approaches that illustrates my point:

SCRUM by definition:

During a sprint, no one is allowed to change the sprint backlog, which means that the requirements are frozen for that sprint. (a sprint is typically a 30 day period)

From the principles behind the Agile Manifesto:

Welcome changing requirements, even late in development.  Agile processes harness change for the customer’s competitive advantage.

SCRUM manages the risk by locking things down at some point and avoiding the conversation.  After all, the next release opportunity is only 30 days away.  Yet Agile foundations encourage a certain amount of flexibility and consideration. Being customer focused means sometimes taking the risk.

Make sure you check at the Agile Manifesto.  I would have given anything to be a fly on the wall during that discussion!

How late is too late?

We can certainly agree that if the software is going live tomorrow, responsibly we should only fix critical issues that render the product not releasable or worse yet that might corrupt customer data, right?  Other than that, there isn’t enough time to re-test everything and even the best guys make simple mistakes.  But what about embarrassing spelling errors or showing a login name with a poster’s comment?  The team can fix something as easy as that, can’t they?

Assuming the feature truly is important enough to consider, here’s what you should ask yourself:

  1. Is there enough time to do the change and test the change?
  2. Do we have someone we can free that we trust?
  3. Is the impact of not having it worse than the impact a mistake could have?

If you can get a yes to all 3 of these, then the risk is worth it.  If not, then you are pitting customer satisfaction against customer confidence if you make the wrong call.  Technical leaders in general would not proceed.  Individual changes are rarely that important in their eyes.  Product managers and execs almost always say go for it under the guise of “we can’t afford to wait.”

Breaking this problem down might not be as hard as you think. Put your late feature decisions into one of these buckets:

No brainer in – Yes, yes, yes to all three questions above.  We can get it done and tested and we have a guy we can free up.  It’s safe so let’s go for it.

No brainer out – The answer to most questions above is no.  There isn’t enough time, no one is available or the risk of mistake is far greater than the benefit to the business.  Don’t forget that customers often don’t miss what they don’t know about.

Hard calls – The answer to at least one of the 3 questions above is no.

The only bucket to keep you up at night is the hard call.  For me, the decision almost always comes down to the code base and the team.  Is the code base solid enough where I can take risks?  Is the team good enough where I can trust them with this risk?  I have been at companies where the leadership doesn’t understand why we don’t go for it.  The blocker is often that we are managing some level of legacy code that can’t be rushed.

I think that’s the hardest part.  Leadership and investors want companies that can release every two weeks.  Even with our own product hinventory.com we are following a release frequently strategy and it is working well. But if the product or team is not set up for quick releases, then I am sorry the answer is probably no…

…for the hard calls anyways…

…we can put the change into the very next sprint…

…are you crazy…

…do you really think that feature matters that much to risk the release…

…we’ll keep the change isolated and release it a few days after…

…maybe we can go for it but if we see any adverse effects we are reversing the change…

…it’s in the product but we’re going to keep testing after release and stay ready with a hot fix…

…see you all Saturday, at least the company is buying dinner…

I did say it would be an honest discussion.

Filed under Development Management Tagged with

Understanding Web Development Resources

March 10, 2010 1 Comment

You have a great new idea.  It’s a Web site or a product or some technology that can become the foundation of other solutions.  What kind of team do you need?

Outsourcing removed the interview process from setting up your team.  For many start-ups, that change normalized the resource pool as many outsource providers simply assign a team to the project.  In reality, there is a big difference between a developer who knows how to build an online Web store versus someone who can make Twitter scale or conceive of Ruby on Rails.

Let us help explain the difference between these types of resources.  First, we need a pyramid!

Companies have different levels or terms for engineers.  Here’s how I define them:

Web developer — A Web developer is good at creating sophisticated Web sites that have limited back end functionality.  His tools of choice are HTML/CSS/Javascript or Flash.  He loves walks in the park and open source CMS’s.

Software engineer — Software engineers are comfortable building more complex functionality that includes objects and business logic.  Ruby on Rails is the language Du jour for the hip and trendy alternative scene.  PHP is the blue collar worker’s hammer.  Java is the choice of old school guys who think the country has gone to the dogs.

Software developer — We don’t use objects, we are objects.  Pearl Jam is the new Grateful Dead.  If you haven’t modified a Unix kernal or developed in native C, then you are a poser!

Software architect — The architect is smarter than most of us, and you should avoid the ones who know it.  He spends his weekends looking for quasars or trying to eliminate a contradictory systemic anomaly from what is otherwise a harmony of mathematical precision.

For most of your projects, your team will likely be a collection of software engineers and web developers.  The more complex the project, the more you will need developers or possibly a seasoned architect.  The pay scale rises with qualifications obviously so we tend to look for one or two smart senior guys and then back fill with a cost effective pool of highly motivated individuals.

We took a look at our some of our projects from last year and charted them against the pyramid.

Understanding the type of project you have will help when selecting your team*:

Website or application – A Web site project in this case is a project that is mostly user interface with either little or standard back end functionality.  The site might have e-commerce, user sign-ups and dynamic content.  Back end functionality is supported by existing open source tools or by integration with other sites.

Product – Product development generally includes sophisticated back end functionality along with more complex interfaces.  The project often is based on some “secret sauce” that is protected IP, under a patent or otherwise considered a market differentiator.

Framework or foundation – Framework or foundation projects are projects that create technology upon which other solutions are created.

We’re product developers and like to produce complete solutions for our clients.  Framework projects are fun and challenging though there are simply less of them.  Of course, we love a good Web site project as well.  It’s just that they tend to be shorter and require more customization work than software engineering.

Next time you start up your a new project, it might help to classify the effort within this pyramid.  You can use the classification to define what type of engineers you should be asking for.

* A complete discussion of resources should include specialists and other disciplines including designer, tester, project manager and so forth.  I am working on a follow up post to help that aspect of your resource planning.

Filed under Development Management Tagged with , , , , , , ,

Design Lessons Learned Example

February 27, 2010 1 Comment

One of our top posts so far this year is our post about design lessons learned in 2009.  We provided suggestions that might help you successfully complete your design project along with examples of our work.  The key tips we presented were as follows:

  1. Start from a creative brief
  2. Use multiple visuals
  3. Plan to start over at least once

At the end of the post, we showed a hint of a work in progress.  We now can say the mock-ups were from our new product hinventory.com.  You can learn more about our launch in the hinventory.com blog.  We thought we’d go through the design steps in more detail to help illustrate the tips presented above.

hinventory.com started from a real need in my own life.  I had previously gone through the painful process of cataloging everything I owned in excruciating detail. The process was time-consuming and I soon gave up maintaining the list as do most people.  Late last year, I was thinking about the simplest way to get this done when it hit me that all I really wanted was take photos and mark the significant items in the photo.

First, we wrote some specs and did a creative brief to better define the product.  I can honestly say I am addicted to the creative brief at this point.  There’s nothing like collecting your thoughts to focus what you are trying to do.  I may even start doing them for house projects or working in the garden!  The graphic below is our proof of concept piece that went with the creative brief to help define the product.

Once we understood the direction, we set about developing the product.  The first version was intended to be a working prototype or beta that we hoped to get some users testing.  The interface is presented below.  Feedback on the product confirmed the market opportunity. But…

… the interface faced some challenges.  When developing functionality you sometimes make design compromises in the name of productivity you later regret.  This interface looks like it belongs on the TV show Romper Room for those of you who remember that.  The logo and banner are straight from a 3 year old’s bedroom.  It doesn’t work, I know.

Lesson learned.  Start over.  Get some fresh eyes.  Maybe hire a graphic artist.  We did.  We used one of our favorite artists in Costa Rica and she didn’t disappoint us.

The above interface is the one we selected over the examples in our lessons learned post.  The interface is clean, intuitive and aesthetically pleasing.  Putting the content inside boxes though can lead to problems later on.  If I had to list a fourth lesson learned from last year, it would be to design for functional expansion and page growth.  We did another round of mock-ups using less restrictions on the actual page content.

We selected number 3 as the final design and then moved on to the logo.  Here are the samples we created before sending a few select ideas to our artist.  Using multiple visuals proved key for illustrating to our artist what we liked and what we did not.

We ran into one final design issue during the course of development.   Take a look at our iPhone application mock-up below and see if you notice the issue.  We created the mock-up ourselves.  We’re launching the app next month so keep your eyes and ears open.

Do you see the issue?  The problem was the markers.  They are barely visible.  The same issue existed in the Web version, but we hadn’t noticed it as much until we saw the photos on the iPhone.  Marking items is essential to both applications.  We moved to a red marker inspired by what you see on a map.  The final interface markers and all is displayed on our product page.

You can see the product yourself by signing up on hinventory.com and using the product.  We hope you do.

Cheers.

Filed under Development Management Tagged with , ,

Design Tips from Lessons Learned in 2009

December 9, 2009 3 Comments

We had some fun and rewarding design projects this year.  Open Mountain has a new logo and Web site, and we executed a new ad campaign.  We also designed sites for our clients and were involved in many creative projects throughout the year.  I think it’s time for a little retrospective.  Before I take you through some of work, I thought I would provide some lessons learned from the year.  Assuming you are following a healthy design process, here are some tips to help you achieve success with your creative endeavors:

1) Start from a creative brief

A creative brief synthesizes the desired results or impacts of your project.  I recommend a single page brief that has 3-5 words that describe the emotion you wish to evoke, a sentence describing the impression you are trying to create or message you are trying to communicate, and then 5-10 bullet points listing everything that should also be considered.  We skipped this step a couple of times only to find out later that our lack of alignment was driving the design in different directions.  Resist the temptation to dive right in creating images before you collect your thoughts.

2) Use multiple visuals where ever you can

This one seems obvious.  Of course you are going to create visuals of your design.  We recommend using more than one as much as possible and use existing work for inspiration.  We started our logo project by creating a page of logos we liked from other sites and a page of logos we didn’t like.  Our Web site went through many prototypes before we started working in HTML.  Our design partners deliver 3 to 5 design choices per deliverable and that gives us plenty to discuss as we strive for something creative, intuitive and unique.

3) Plan to reset or start over at least once

All our best design projects hit the inevitable “we’re stuck” moment at some point in the project.  The current trajectory has run its course.  Where do we go from here?  Starting over allows you to dump the bad parts of everything you did while retaining the best of your brainstorming and thinking.  For our logo project, we liked the two-tone nature of the images but couldn’t converge on colors.  We realized that using brown to represent the strength of mountains was putting a damper on our brand.  Hills in California offer other choices such as green for spring or gold in fall.  The logo design direction was good but we dumped our color palette and started over.  You’ll see that progression below.  We recommend you embrace the set back as a healthy part of a creative process.  Try not to resist just because you are under deadline.  It may take you longer to make a bad design better than create a new design that works.

Here now is a trip down some of the design projects from our year and how we came to learn these valuable lessons.

Open Mountain Gets a New Brand

Our first project of the year was a new logo and Web site.  As I mentioned above, we did the logo ourselves starting from a creative brief.  Open has strong connotations for approachable and transparent but also open in the open source sense implying community and knowledge.  Mountains are strong, substantial and impressive.  The image below shows our progression from earthy colors toward what we have today.  This project benefited from all 3 tips listed above.  We used a brief.  We created mountains of visuals to consider different options, pun fully intended of course.  Our earth tones palette was replaced by something green, open and fresh.

We tackled the Web site next.  Below is our first attempt starting from our existing creative brief.  Do you see any major issues with this perhaps after reading our previous post about design?  You see a guy in a kayak against a mountain range exactly where the eye looks first on the page.  How informative is that?  We had hoped that the serenity of the lake we create a peacefulness when perusing the site.  One reviewer thought we were a travel Web site.  Furthermore, most people didn’t even look at the content at the bottom because it appears secondary to the overall page.  Time to start again.

Our new design started by utilizing our own advice and putting meaningful content in key positions.  We decide to use Flash animation to make the experience more engaging.  Below is our first shot at the flash panels for the animation.

Next we played with color and attributes to encourage the users toward different sections of a page.

In the end, we feel we created a site that is informative and engaging, and delivers the right message about our company.  Take a look and tell us what you think.

We Have Ads Now!

Our next project was creating advertisements for our business.  We procured several 250 by 250 spots on various Web sites through pay or partnership.  Due to timing constraints, we were forced to create something quick and dirty to meet a deadline.  This is what you get when you don’t follow good process or utilize any of the design tips we mentioned above.

Is there anything in this ad that is the least bit engaging?  What incentive do you have to explore this company?  What service do they really offer?  Right, you get the point.

We reset the entire project and thought hard about what were trying to do.  An expert gave us some advice on how to think beyond our current approach.  She talked to us about advertising and about how you create something like a “Got milk” or “Just do it”.

We have said from the beginning that we wanted to be different from what customers have come to expect with outsourcing.  We strive to overcome the separation between organizations and instead work to provide insight into what is really happening with the remote development team.  Working with Open Mountain should not feel like typical outsourcing.  It should feel like your own team.

Outsourcing never felt like this!

That was it.  We knew right away this was our “Got milk”.  When you outsource with Open Mountain, it should not feel like any previous experience you might have had.  Below is our first concept piece with the new approach.

Happy smiling people.  People actually enjoying outsourcing.  Exuberance.  Feedback from our experts confirmed this had appeal and communicated the right message.  We created 4 ads.  Here are the two favorites and we also used the one in the upper left corner above.

If you outsource with us, you’ll be as happy as a kid sledding or a crazy guy eating a huge lollipop.

These ads still crack me up.  They are quirky and unique and communicate our core message.  Of course, we rejected some ads as well.  Here are the two most controversial.

Outsourcing should feel like you are about to eat a huge hamburger, right?  People said he looked constipated or nervous.

Reaction to the woman eating cake was truly mixed across woman and men.  At the time we rejected the ad, one woman reviewer was saying this degrades our business while another said this would get the attention of our target audience.  Let’s just say that the ad did not fit well with our corporate values.

Clients Restart Projects Too

Design tips were learned working with clients as well.  Our client ThriveOn.com launched their site based on the design below.  As we added features to the solution, we soon realized that the design was creating some challenges.  This design is more consistent with a Web portal such as iGoogle or my.yahoo.com, and didn’t fit well with upcoming product changes.

The client went back to the drawing board and created a design more suited to the long-term growth plans of the product.  Below is an interim step from when we experimented with different color schemes.

The final site is presented below.  You can read more about our work with ThriveOn in our case study on the OpenMountain.com.

A Look at a Work in Progress

The year isn’t over yet and we’re designing new products all the time.  We strive to follow good process and utilize the tips mentioned at the start of this post.  Here now are two final mock-ups from a product we are working on.  The project is in stealth mode and some content is redacted.  Overall, the design process has gone very well.  Our favorite approach is not displayed below however.  You’ll have to wait until launch to see where we ended up.

Filed under Development Management Tagged with , , , , , ,

Developing on a Platform Creates a Dependency

November 2, 2009 Leave a Comment

Companies are finding real benefit from starting on a platform that provides functionality and existing customers.  More and more developers are launching products on the iPhone, facebook and SalesForce.  We definitely encourage our customers to use existing technologies and services to expedite time-to-market.

A few months back, we were proposing to build a facebook application using some other technologies as well.  In our proposals, we like to think ahead to point out issues that could arise and we stated that any changes to these technologies could impact the schedule.  At this point, the customer emailed me an interesting question.

How do we mitigate the risk if facebook or the other technologies change?

Our customer was asking a pretty good question.  If facebook changes their API or markup language, we may have to re-factor significant amounts of code.  Don’t think this could happen?  It already did.  Here’s how it impacted some developers.

At first I was tempted to say that is the nature of the beast.  If you are building a house and it starts to rain, construction will be impacted.  Materials will get wet.  You might have a major disaster if you just poured the foundation and the cement hasn’t cured.  We can’t stop the rain.

I then realized this is a profound question and that I needed to give it some thought.  We develop for start-ups all the time and a significant delay from outside influences could prove disastrous.  I started thinking through the possibilities.

First, we need to consider if companies we are depending on actually appreciate this risk.  How often does the facebook API change?  How does SalesForce improve their platform without breaking existing applications?  It’s reasonable to conclude that if Apple, facebook and SalesForce care about their business they wouldn’t adversely impact people making a living off their technology.

I did a little investigation to see how well these companies keep their developers informed of changes.  Everything I discovered was as of the writing of this post and may have changed before publishing.  I certainly welcome anyone from facebook, Apple or SalesForce to comment on this post and provide information I may have missed.

facebook clearly embraces developers as a community.  Their WIKI is comprehensive and includes a link to view the latest changes to the platform.  A proactive developer could sense changes were in the air for sure.  I was hoping to find a way to subscribe to emailed changes.  I’ll keep looking for that.

Apple’s developer site feels very polished.  They clearly focus on information presentment making it easy to find documentation.  That said, the site seemed to offer less insight into what is happening with the platform.  By way of contrast, WIKI community sites are easy to edit and therefore updated more frequently, but often contain posts that are not completely accurate or have become out of date.  A good editor solves this problem of course.

SalesForce.com is definitely going the community route.  The developer site includes documentation, news, events, updates and discussions.  An active developer can stay abreast of changes for the most part.  After looking at the site, you can see that the company is making a good effort to keep the developer community informed.

Back to the question, how can we mitigate the risks of a key technology or platform changing mid-cycle?

Here are some the techniques we recommend for staying informed and managing the risk from developing on existing technologies and platforms:

1) Subscribe to all change lists – The best way to find out if an API or technology is changing is to have the company tell you in advance.  Trust me, you don’t want to find out from users your site is broken.

2) Avoid developing functionality that has a shelf life – Some times, it is clear an API or functionality may have limited long-term viability.  Certainly privacy and security issues won’t stand over time on any site with significant usage.  Developers love to exploit a loophole or over reaching function.  Your business might be doomed if this loophole is core to your success and it gets closed.

3) Plan for scenarios in the business – The corollary to point 2 is plan for the unfortunate or unexpected.  You should certainly utilize any advantage you reasonably uncover.  Just don’t bet the farm on anything that may pose a long-term issue for the platform without a backup plan.  Spend time thinking about how your business would need to adapt.

4) Create a business that is truly platform independent – Try to see each technology used by your product as a component instead of a necessity.  facebook could be swapped out for MySpace or Twitter for example.  If you use an open source product for your shopping cart or CMS, consider having a backup choice in case you find a bug that can’t be fixed.  Ask your architect to present an alternative technology stack that changes all third-party technologies just to prove it can be done.

Experienced teams use existing platforms and technologies to enhance products, speed up development and create forward-looking solutions.  You should too!  Just don’t get caught depending on something that would hobble your business if it changed.  Have a plan to get back up if the rug is pulled out from underneath you.

Filed under Development Management Tagged with , , ,

← Older posts

Follow

Get every new post delivered to your Inbox.