Archive for the ‘How we work’ Category

Adding effects to your website

Tuesday, October 16th, 2007

This post might be a little over the standard in terms of technicality. But then, this is a developer’s blog, so why not enlighten you. In this episode, we are going to teach you how to add very simple effects and animations to your page.

Over the last few years, the term AJAX and web 2.0 have become synonym with bleeding edge web software. Although we are not going to show you how to do AJAX, we will show you how to use some of the really nice javascript animations that are available in today’s web 2.0 world. This short tutorial DOES require that you know of some HTML and that you have put your eyes on javascript before. So let’s get this started.

We’re going to take our starting point in the Scriptaculous javascript library (which is an extension of the prototype library). The combination of Scriptaculous and Prototype is what we have used at motigo from the beginning.

We start out by having a <div> layer, which is a standard element in HTML. Our <div> looks like this:

<div id="my_element" style="width: 200px; height: 50px; background: red; color: white; padding: 5px;">
  This is the content inside the DIV
</div>

The code above produces this: (a box with the dimensions of 200×50 pixels, a red background, white text, and an inside margin of 5 pixels)

This is the content inside the DIV

Now - we can begin to manipulate it. Notice that the ID of the DIV is my_element. That means that we can do this (with scriptaculous and prototype loaded):

<a href="#" onclick="Effect.toggle('my_element', 'blind'); return false;">Toggle blind effect</a>
<a href="#" onclick="Effect.toggle('my_element', 'appear'); return false;">Toggle appear effect</a>

This produces this:
Toggle blind effect
Toggle appear effect

Try to click the links and see what happens with the red box.

Pretty neat. Pretty simple!

The reason why we say return false; in the end of the onclick="" attribute, is that we don’t want to redirect the browser to the link of href="".

What allows us to do all this, is because we have Scriptaculous and Prototype loaded on this page. We have done so, first by downloading the Scriptaculous and Prototype files over on the Scriptaculous website, uploaded these files to our server, and including the following HTML code at the top of our page (inside the <head> tag):

<script type="text/javascript" src="/js/prototype.js"></script>
<script type="text/javascript" src="/js/scriptaculous.js"></script>

The downside of using Scriptaculous and Prototype is it’s large size (in kilobytes). Other smaller libraries include Dojo, MooTools, and Ext JS.

Let us know if this is too advanced, or if you would like to know more.

UPDATE: This article seems to have hit a too high level of complexity. We are sorry if all this doesn’t make much sense. The primary problem our readers have experiences is that they are not aware that they need to upload the javascript files from Scriptaculous and Prototype to their own server - and that it is those files that allow us to do the effects.

NOTICE: The effects work in the most popular browsers. Some older browsers are not supported.

Build your website from reusable components

Tuesday, October 9th, 2007

Building an entire new website from scratch is a large task. To ease the task, we often tend to fall back and reuse parts of old websites we have created. This is how you evolve your own look-and-feel. As we develop more and more websites, our vocabulary of possible outcomes of a website designs increase. We thus become better at building websites over time, as our over time larger design vocabulary lets us pick and choose exactly what we want. Our designs in this way become more and more refined as we develop more and more websites. Our experience grow.

We are all in the same boat! What separates us is the magnitude of our experience: the number of websites we have created. You, the reader might just have created your first website, or you might be a veteran - either way you are in quest for the same thing: to expand your design vocabulary.

Fortunately, we are all in luck. Several individuals and organizations have been jotting down their experience in website design, and put it out for free on the internet for you to use. These websites hold collections of user interface design patterns. In formal words, design pattern are:

“…recurring solutions to solve common problems…”

Source: ui-patterns.com

Jennifer Tidwell continues:

“Each of these patterns (which are more general) and techniques (more specific) are intended to help you solve design problems. They’re common problems, and there’s no point in reinventing the wheel every time you need, say, a sortable table — plenty of folks have already done it, and learned how to do it well.”

Source: Designing Interfaces

At motigo, we find design patterns extremely useful. This is why we would like you to get started using them. Why not harvest the knowledge of many experienced designers before you? Start out by checking out these sites:

How have you used design patterns? And have you been using them without knowing about them?

Designing events view in motigo calendars

Wednesday, August 15th, 2007

As we had built the recently launched motigo calendar, we quickly realized how important the events view was. You can add events to your calendar in two ways. One is subscribing to a news feed, the other is through the events overview page.

The events view is the page where all of your own events are listed (feed-events aren’t listed here, as you cannot edit them). The list provides edit links, so that you can alter the details of your already added events. So the primary purpose of the event view is to let the user browse through all of his events in a quick way, in order to find the exact event the user is looking for.

The peculiar thing about a calendar is, that you can both have events in the future and in the past. The most relevant events for the user will most likely be centered around today’s date, and not in one of the extremes: past or future. This also means that it does not make sense to sort events by their extremes (by the event with the oldest date or by the event with the most future date), but rather by the center: today.

At first we had just chosen to list the events ordered by id - that is ordered by creation time. This would put the most recent added events on top, and thus provide feedback for the user to let him know that his event has been added (as he could see his newly added event on the list). For feedback purposes, this list worked great. But if you wanted to find that specific event you to either edit or delete, the browsing through pages of events sorted by creation date was not acceptable. You could of course search for the event, but then you would need to know what the title of it was.

Ordering the events by start date does not make sense in itself either. The most relevant event is not one that starts in 2012 and not one that happened in 1995.

When looking for a specific event, you always know that it either hasn’t happened yet (in the future) or that it already happened (in the past).

Introducing today’s date as the center of the events view:

Adding today as the center means that you can know browse in two directions: either further back in the past or further ahead in the future. We therefore introduced two paginations: One for pages in the future and one for the past.

This view works much better as the most relevant events (the ones closest to now) will always be shown on the base page of the events view. You can then choose to browse toward either of the extremes (past or future).

Having to pagination directions is all nice, but if you haven’t filled your calendar up with that many events yet, you don’t want to be bothered with information about how you can browse the future or past- you just want the few events you have to be shown.

So the last thing we added was that. The fancy pagination arrows in the left margin are hidden when you just start and will get shown once you have use for them.

We also added the capability of looking up a specific date as a nice shortcut to finding the events you are exactly sure when is.

Developing software is not always straight forward, if you want to deliver a nice user experience as well. We hope that his insight into how we conduct iterative development will help you continue your progress in developing the perfect website of your own.

New account overview

Friday, June 15th, 2007

Things are really starting to get better at motigo!
We are very happy to announce the launch of the new account overview. A feature that was both widely requested, but also extremely important in bringing the motigo services together.

When we first launched motigo in the end of March this year, the most important thing for us was just to get motigo up and running. It is now - a few months later - that we can actually start to tweak motigo into being what we actually want. The new account overview and the recent “frontpage redesign”:http://devblog.motigo.com/2007/06/04/redesigning-the-frontpage-step-2/ are some of the more visual steps we have taken in this direction.

As usual, we will give you an insight into the design process.

As opposed to earlier redesigns, we actually didn’t have anything to redesign! The account overview has been non-existent until now. We wanted the new page to fulfill a list of things:

  • First of all, the overview should bring all motigo services together: giving an overview
  • The page should function as the natural “home page” - the page you always end up on when you want to do something new
  • We wanted as much of motigo to be accessible from only one page
  • We wanted to communicate the colour scheme of motigo, where each service has its own color

Our first thought was to reuse the toolboxes we have so far used for the forum/guestbook/shorturl admin pages as these had the color of the respective service in the header. The result came to look like this:

Account overview - proposal 1

We chose to take the approach of designing everything straight and only in HTML instead of taking the usual photoshop way that many designers choose. Doing the design in HTML only gave us several benefits:

  • The actual interface is at the center of the attention at first. There is no spec: the interface is the spec.
  • An interface is not a wireframe that we can just slice up and magically transform into an HTML document. Neither is it a photoshop mockup.
  • Creating a mock-up of the interface in photoshop will produce a design that matches the constraints of photoshop - not the constraints of HTML. We should therefore “embrace the constraints”:http://gettingreal.37signals.com/ch03_Embrace_Constraints.php of HTML.
  • When we build it only in HTML, we can actually use real and live data while building the design. This helps surfacing problems that photoshop would otherwise hide
  • The interface is at life from start. You can click it, try it out, and feel it.
  • You will get something that works very soon in the design process
  • There is no monster integration in the end.

Although the new and colorful proposal was better than anything we had before (we didn’t have anything) - it was too much. Too colorful and tivoli like. Plus - the boxes approach to showing each service did not always line up nicely, when a user had services in one category than the other.

The next approach was to list the services in one big list and now side-by-side. We removed the colorful header of each service and give it a more settled look:
Account overview - proposal 2.1

This however proved to be a little too settled. This meant that we didn’t get to indicate any of the colors of the services. So we added a little bit of color:
Account overview - proposal 2.2

Again - this was too much. The final solution would be just to have a small box indicating the color of the service:
Account overview - proposal 2.2

We also wanted to add several things to the overview page, so that the user would go there as a natural thing to find just the information he wanted to see. These things included basic information about the logged in user: his name and email, but also the current time in the timezone he had selected. As we have users in many different countries, setting the timezone of your account has huge importance as it will determine the time of your forums and guestbooks as well as the base time in your statistics. We also added links to often used and important documents such as FAQs, terms of service, and of course the developer blog ;-).
All this provided the necessary detail to make the Account overview feel like a real motigo home…

Account overview - toolbox with account links

Along with the overview, we’ve also added a toolbox that is placed in the same spot on all admin pages, so that you can always find your way to the most important pages of motigo.com. This continuity was greatly missed in the old version of motigo, why we are relieved that we finally got it online.

Searchbox

We also got rid of the top bar with the list of our services, as we now have this list a more natural place: in the account overview. Instead we added a search bar that we plan on expanding to be able to do more in the near future.

We really hope that the newest updates has helped your experience of motigo.com. We are extremely happy about the release ourselves and hope that you will be as well.

Now, go enjoy the new “motigo”:http://motigo.com

Account overview - end result

Redesigning the frontpage step 2

Monday, June 4th, 2007

We earlier described the long iterative process it was to redesign just a banner on the front page of motigo.com. We recently launched the last part of the front page redesign, which was a result of an even longer iterative task of trial and error.

The starting point for the front page redesign in the start of May 2007 was:
Front page of motigo.com - start of may 2007

*We had several things that we wanted to change in the old layout.*

  • We wanted to promote the “Developer blog”:http://devblog.motigo.com
  • We wanted to get rid of the bottom “how it works” box that explained that you could signup and get access to our services - only through icons. It was an idea that looked good in the eyes of our designer, but confused more than did good in the eyes of our users
  • With the new front page top banner, it did not make sense to have the signup box so close to the signup-button of the top banner
  • The graphics that showed how the blind-down worked was outdated - and is soon to be irrelevant (oops - did I say too much?)
  • The static content explaining what motigo.com was all about was more confusing more than explaining.

As soon as we had the change, we changed what we could and removed the bottom “how it works” box, put in a box printing an excerpt of the latest developer blog post, and moved the blue signup banner down lower on the page.

Front page of motigo.com - mid-may 2007

But, what is motigo?

When conducting “heuristic evaluations”:http://www.useit.com/papers/heuristic/heuristic_evaluation.html on motigo.com or in other words: When letting potential users browse motigo.com in order to find usability issues, the most often heard quote was: “But what do you do? What can I use the site for?”. Admittedly, this is far from the result we wanted to hear, why we took immediate measures to improve the general usability of motigo.com. The frontpage is only the first of many great changes to come.

Even though we in clear text explained what motigo was on the front page, users answered that they didn’t understand what our concept was. They admitted that the new “frontpage banner”:http://devblog.motigo.com/2007/04/27/redesigning-the-front-page-v1/ had helped dramatically on their understanding, but that they could still use some more guidance. It came clear to us that our visitors did not all visit our “about pages”:http://motigo.com/about/services to find out what motigo is, but sometimes gave up on the front page, when they could not find an immediate answer.

We needed to more clearly communicate what motigo is about - without too many unnecessary distractions. Based on heuristic evaluations and what our analysis told us, we agreed to concentrate on showing:

  • *Screenshots* of our services
  • *Explanations* of each service and motigo.com *that make sense*
  • An excerpt of our Developer blog, as this communicates who we are and what we stand for
  • Easy access to sign up

Finding a way to show screenshots of our services in a manner that matches the cleanness of our general look and feel was a dificult task. We had several solutions up on the table:

Screenshots proposal 1

*Proposal 1:* Looked clean, but did not give room to explanations of each service.

Screenshots proposal 2

*Proposal 2:* Trying out the bubble layout from our about pages. It unfortunately did not fit all of our services in the way we wanted.

Screenshots proposal 3

*Proposal 3:* Showing the screenhots alone without too much extra graphics turned out to be a good solution. At the same time, we could put in explanations of each service neatly together with each screenshot.

Screenshots proposal 4

*Proposal 4:* Adding the color code of each service gave the final touch that added the right amount of style and nice feel to our front page that we feel suit motigo. It also helped show that we use colors to distinguish between our services and what those color codes are.

When inserting the new screenshots and accommodating explanations of each service, the frontpage came to look like this:
New frontpage of motigo.com - ultimo May 2007

We are very happy with the result and have now started working on a redesign of the webmaster administration area, that will bring coherency into play and give a great overview of all your motigo services.

We also have plans to create tutorials and guided tours for each of our service.

Rapid feedback and multiple languages

Tuesday, May 1st, 2007

One of the biggest advantages of developing “web applications”:http://en.wikipedia.org/wiki/Web_application as opposed to “desktop applications”:http://en.wikipedia.org/wiki/Application_software is their often “short development cycle”:http://www.extremeprogramming.org/rules/iterationplanning.html. “Lightweight development methodologies”:http://www.extremeprogramming.org/light1.html with short iterations (development cycles) allow for the developers to react more rapidly on feedback from the customer and the product’s users. There is a relatively short path from when a feature is suggested until it can possibly be implemented.

As both desktop applications and web applications grow in size, it gets increasingly harder to react rapidly towards customer feedback in order to point the developer’s attention in the right direction. As applications grow bigger, a small change to the software can possibly effect many parts of the whole application, why each new feature gets increasingly cumbersome to release as the product grows in size.

To be able to react to changes in its environment, the application should always be the “simplest possible implementation”:http://en.wikipedia.org/wiki/Refactoring possible.

At times, the fundamental requirements of the application go against the goal of always having the simplest possible implementation. To stay “agile”:http://agilemanifesto.org, this dilemma needs clever and flexible attention.

At motigo, we have services that originate from multiple countries. “Motigo Webstats”:http://webstats.motigo.com was originally nedstat - a Dutch website, and “Motigo Forums”:http://motigo.com/about/forums, “Motigo Guestbooks”:http://motigo.com/about/guestbooks, and “Motigo Shorturls”:http://motigo.com/about/shorturls were originally “webtropia”:http://webtropia.com/ products - a German website. This means that our primary users are from the Nederlands and Germany - thus we have a need for more than just one language.

We currently have everything in 5 languages. This has put a serious barrier for us to be able to make rapid changes and react rapidly upon feedback. Every time we want to make a new screen, or just make changes in the existing practice, we need translations in all of the 5 languages that we currently support. This means that many changes that has been thoroughly tested and are ready to go public have to wait several days for our translators to finish their job.

A clever and flexible solution to cope with this problem in all contexts is still something we aim to find. If any of you have any experience with this, we would love to hear from you. However, for changes that have to do with presentation, we already found an approach that works fine.

As an example, in our process of “redesigning the front page”:http://devblog.motigo.com/?p=5, we started out making the changes visible only when you had chosen English as a language.

This proved effective, as we had made several changes based on user feedback even before the first translations rolled in. If you’re quick, you can even see that at the moment, it is only for English, German, and Dutch, that we have the new frontpage banner implemented. For French and Spanish, the old flashy banner is still showing.

When starting out by only implementing changes in English, which we (the developers) are all fluent in, we can again start to react rapidly on feedback instead of having to wait 4-5 days for all translations in all 5 languages.

As our plan is to implement 7 more languages (12 in total) in the new future, the dilemma will become increasingly more important to cope with in a clever way as we move along.

Again - if any of you guys have any input about our dilemma with wanting to push the features out to you as soon as possible and still having 12 languages to cope with, then please comment this thread and let us know.

Redesigning the front page step 1

Friday, April 27th, 2007

We are constantly trying to make small tweaks to make motigo a better place for you to spend your time. We strive for a usable yet aesthetic website. The fine balance of aesthetics and usability can however be tough to find. It is a often a result of a long iterative process of trial and error rather than a magic splash of geniality from our designers. For each little change you see in our products, such long process of trial and error lies behind. Creating the perfect website for you to use requires much effort and energy.

As an example, I will take you through the process of redesigning the front banner on motigo.com. It is a part of a total redesign of the front page - just a part of yet another iterative process.

When we first launched motigo in beta, we had a “flash banner”:http://motigo.com/images/motigo_en.swf showcasing motigo and our main products. Although this banner was pretty, flashy, and had some “wow” effect to it, it did more wrong that it did good. It left visitors saying “nice site, but what is motigo?” Of course, our egos could not live with this, why the process of designing a new and more friendly welcome page (and banner) began.

The starting point in the beginning of April 2007 was this:
motigo.com - April 2007

We had several goals for the redesign, although becoming aware of these we just as much an iterative process as designing the graphics itself.

*The goals for the redesign were:*

  • The less reading required, the better
  • The clearer the statement, the even better
  • Simplicity over “featuritis”:http://headrush.typepad.com/creating_passionate_users/2005/06/featuritis_vs_t.html
  • What motigo can help you with needs to be clearly stated
  • We wanted to clearly state what services we provide and what they are
  • To start take advantage of our free services, you need to sign up
  • A very important selling point of motigo needs to be stated: *it’s free*

The frontpage banner looked as this:
motigo.com -front banner v0

It didn’t really fulfill any of our goals.

It had a lot of text that was too small and too long to read (and too boring as well). The flashy effects of the banner gave the page a severe featuritis. When you moved your mouse pointer to click a service, the banner moved into something different. When you finally clicked anything, you were just taken to the sign up page instead of being presented with a proper page that could elaborate on the service clicked. It obviously didn’t work.

motigo.com -front banner v1

The first redesign captured a lot of our goals. The reading had been drastically reduced. The message was getting across much better. We now state what we can do for you, and with what tools we can help you kick ass. The featuritis was gone.

The banner was however one big piece of graphics, all linking to one page. We also needed to state that you need to sign up to get access to our services. It was however much better than the prior banner, why we put it up on the page immidiately. After a few days, we had ideas of making it much better.

motigo.com -front banner v2

The next redesign first and foremost included a sign up button. The background color of the banner was made brighter, and to illustrate that a signup would give access to all of our services, we made a gradient background becoming brighter towards the sign up button.
We also had an overuse of the motigo font (Yup, we have our own specialized font. Pretty cool, huh?), why the Tahoma font of the rest of the site replaced the subtitles of each service and of the main message (to the left).

motigo.com -front banner v3

Next, we realized that we left out the most important selling point of our services: *it’s free*!
This is why we added a banner showing that motigo is free. Realizing how important this actually is for how we help you kick butt, we made the “FREE FREE FREE” banner even bigger and darkened the font:

motigo.com -front banner v4

Tadaa! And that concludes the trivial task of designing a new welcome banner. On an after thought, we are aware that we shouldn’t bloat the banner too much with extra small banners and small gizmos. Then we’ll just end up creating a “parody”:http://video.google.com/videoplay?docid=36099539665548298 of the starting point.

Much work goes into the smallest task. In this way, we are slowly moving towards a better motigo that will help you make your website kick some serious butt.