Am I the only one who doesn’t like the new JCPenney logo? I feel like people have an “Emperor’s New Clothes” complex – no one wants to come out and say it’s bad because everyone wants to believe it works.

JCPenney’s new CEO Ron Johnson is a former Apple and Target retail executive so this guy must have the Midas touch. So of course people are going to flock to his feet praising his good works with little hesitation. I really don’t want to make a Tim Tebow analogy… so I won’t.

Let’s get one thing straight: I don’t dislike what he has done to the overall brand. In fact, I really like everything he’s done so far – except the logo. I get that they are branding around America and nationalism and local businesses to combat the Swedish invader H&M. However, do they have to be so damn literal? What happened to a concept being subtle?

I also understand that they are keeping in line with the box in the previous logo, but the previous logo had no strong concept behind the box. They are building on an empty concept and injecting a cliche concept. Furthermore, I feel like it is about to fall over. It is extremely top and left heavy. I see no balance, no elegance, no subtlety.

leave a commentposted in: opinion

It’s well discussed that service based companies often have a rough go at producing viable products. There is an inherent tension between provisioning resources for products vs addressing immediate billable service work. Pay the bills now, or invest in an uncertain future?

Many who’ve commented on this tension seem to believe it’s either or. Companies that try both often fail at one, or worse yet, they sell both short. At Imulus, we love doing the client work and believe it helps us discover new ideas for products. From day one, we decided client work would always be core to our identity, so the decision to move the company entirely into products just isn’t on the table.

During the last few years we’ve stumbled down the product path. Stacks was rolled out about a year or so behind schedule. Support Details was a quick win, but we’ve been slow to update it with exciting new functionality. In recent months we’ve added several other products to the cooker. This has prompted us to more closely examine the product development relationship with services.

Last month we implemented the idea of a Product Tsar.

The Product Tsar is a temporary 4 month stint with the responsibility to oversee product development. We are currently pulling from our developer team to fill the Tsar role, although that may change in the future. Bruce Clark has been helping to head up Stacks development and has nicely transitioned into this role. The first two weeks are used to gather product ideas, review what’s been accomplished and map out a list of items for development. The co-founders and the Product Tsar get together to prioritize the product development based on a combination of factors including revenue potential, complexity and street cred. We then make a time commitment to the Product Tsar. In this 4 month stint we’ve committed to a minimum of 15 hours of dedicated product work each week.

As the weeks progress, the Tsar reports in weekly, to update our Project Managers and co-founders on the status of products. The weekly status offers the Tsar a chance to gauge how busy the office is and what un-utilized resources could be applied toward product work.

Once the 4 months are over, the co-founders will review the Tsar’s work and the next senior developer on our team will take the reigns.

So far it seems to be working for us, but only time will tell.

leave a commentposted in: concepts

Users find websites for a variety of reasons. For the most part they are on your site to accomplish a goal. Maybe it is to find a product, learn something or download something. I can almost guarantee that they are not there to be confused and overwhelmed by information. I believe that far too many sites are much too complex and confusing for users. This happens for a variety of reasons. We hear from companies all the time how they need to provide vast amounts of information and that almost all of this needs to be accessible from the homepage. Not just on the homepage, but “above the fold.” The result of this becomes as overly complex and overly crowded mess of a site where the user is so overwhelmed by the shear quantity of choices that they simply choose to leave. As with the following example, Continental attempts to give the user access to just about everything they would want to do. As a result the user is overwhelmed and confused.

One reason for this is that there is a general sense of fear that if something is visible on the homepage, that users will not find it. Another is the use of analytics and tools that measure how far users scroll down a page which perpetuates this fear. The flaw I find in this data is that it typically includes all visitors to the site. Anyone who had ever looked at website analytics knows that a site gets a lot of very unqualified traffic from search engines. The behavior of this unqualified traffic can overwhelm and mask the behavior of users who actually intended to be on your site and have a task to accomplish. These users behave very differently and will be more likely to go a few pages deep into the site to complete their task. Target is an example of a site with a ton of content, yet they keep the content on the homepage focused to a primary goal. This makes the experience for the user much less intimidating and invites the user to explore further.

What these qualified users need is a simple experience that gives them clear information that is focused on the primary goals of the site and doesn’t try to do everything at once. One of the reasons that mobile apps are so popular is their simplicity. They are typically focused on a simple set of functions and they rarely require much of a learning curve. People are easily overwhelmed by a plethora of options, so give them the simplicity that they seek. Think about the objectives of your site and distill them down to just a few. Give those objectives the attention that they deserve and you will greatly increase your chances of accomplishing them. The secondary objectives can be pushed lover on the page or deeper in the site. A motived user will find them, especially if they are intrigued by the site and weren’t scared off by an overly complex page. This site for Billings is a great example of reducing choices for the user, and focusing on the primary goals of the page.

Users make decisions about your company within a few seconds of landing on the page. Do you want to have that impression to be one of confusion or would you rather communicate a clear and simple message that will intrigue a user and draw them into the site? So when planning a site, think about the objectives of the site, and then prioritize those objectives. If the site could do only one thing, what would that be?

leave a commentposted in: design, opinion, web design

Here at Imulus, we strongly believe in how important the wireframing process is for all of our projects. Recently we shifted our process in the wireframing stage to lessen the confusion with our clients. We decided not to present wireframes to the client. Wireframes are an essential step in the process for the designer, but they can be a waste of time for the client. The process can end up hurting the project and its goals.

Why?
During our wireframe presentations we noticed that wireframes can cause a lot of confusion. Wireframes that expressed creative layouts were declined by the client because they would have difficulty visualizing the design once fully designed and functional. We’re humans. We have a better understanding of something that we see rather than trying to visualize something that’s shown to us in grey boxes. Because of this, clients approved wireframes that made most sense to them — the one with a very traditional layout.

Traditional wireframe layout

Wireframes are more about content structure — what goes where within the layout. They lack the ability to convey brand-specific features and how contrast impacts content hierarchy.

Wireframes can hurt the project due to the following reasons…

1. They are static — Sure, design is static too, but has a bigger impact to the client than wireframes. Clients want to see the design.
2. They can’t express dynamic interaction — Trying to explain dynamic interaction through wireframes confuses the client even more. In some instances, we’ll prototype specific dynamic features.
3. They can be misinterpreted – Clients can change their mind once they see the design. What they understood in the wireframe can look different to them in the design.
4. They can waste a lot of time – Designers can be stuck in “revision land” for a while. This also affects Project Managers as time is wasted on back and forth with a client.

Our plan here at Imulus is to only do this for website design projects and so far it has been very successful. Web and mobile applications will require wireframe approvals by the client. These projects are complex in context and we want to make sure that the flow of user interaction is ironed out at the wireframing stage.

leave a commentposted in: design, web design

We here at Imulus have spread our wings a bit and decided to get into the Rails game. I have had a crush on Ruby for a long time, causing me to jump on the Rails bandwagon when version 1.0 was in beta. I fell off the wagon before Rails 2 came out, being consumed by development work that wasn’t on the web. When Rails 3 and then Rails 3.1 came out with great support for unobtrusive javascript as well as the asset pipeline, several of us started to get involved again.

We’ve been wanting to continue work on Support Details for some time now. Since it was in .NET sitting on top of a homegrown CMS that it really didn’t need to be coupled to, our frontend developers had trouble moving forward on it. As a lark, I decided to port over the site to Rails. The main functionality was done in a couple of hours and we managed to iron out most of the other main points in spare hours over the next few days. We decided to update some of our detection to be way more accurate, and that took a few more days, but we can now tell if you are on Windows 3.1 running NCSA Mosaic

We didn’t want to stop there though. We were very excited about using CoffeeScript and Sass in the new Rails 3.1 asset pipeline to create readable code that could generate our Javascript and CSS. Taylor and Casey jumped onto migrating the existing Javascript and CSS over to using CoffeeScript and Sass. After running through the asset pipeline which would combine and minify our Javascript and CSS we had significantly reduced our asset download size.

While that was a great first step, we wanted to go further and make Support Details even faster. We started by using Delayed Job to send e-mails on a background queue, rather than tying up the main web thread. Then we decided that we wanted to take advantage of a CDN and so we used the excellent Asset Sync gem to compile and deploy our assets to Amazon S3/Cloudfront when we pushed to Heroku. After all of these changes our initial page load time was cut by more that half.

But wait, there’s more. We’ve had many requests to localize Support Details for different languages. Thanks to the support of various friends of Imulus, we are pleased to offer Support Details in Japanese, Russian, Italian and Portuguese. We plan on adding more languages in the future, and if you want to help in translation please feel free to give us a holler and we can send you a list of phrases we need for the translation.

We have a lot more planned for Support Details, and we have some more great Rails applications in the pipeline which we should be releasing for your viewing pleasure in the near future.

leave a commentposted in: CSS, CoffeeScript, JavaScript, Rails, Ruby, Sass, development, open source