Archived Blog

All the old blog posts, written from 2008 to 2017

Inside the redesign

Everyone’s favourite thing just happened to Adobe® PhoneGap™ Build: a redesign!

If you are a regular user of the PhoneGap Build web-UI, I’m sure that you are experiencing any range of emotions right now - from general apathy to mild annoyance to questionable excitement. Regardless of where you land on that spectrum, I’m here to lay out the logic that drove the redesign in a cold and emotionless fashion. Read on to hear me say my piece, and then please share any of your feedback with us.

BuildBot Begins

Let’s take a moment to remember where we started. I know that we all probably liked the light and airy “white metal” (nobody actually ever called it that … but we could have, couldn’t we) visual language of days past - at least I did. Here it was in all it’s glory:

The old design

Nice, but tons of room for improvement amirite? The question was, what should we improve and how should we do it. In order to keep us on track, we set some goals and established some guiding design principles.

Goals and Principles

There were two primary goals for this redesign:

  • Refresh the visual language
  • Improve common work flows

In pursuit of these goals, our designs were guided by the following principles:

  1. Establish a clear visual priority: direct the user’s attention quickly to the most important information and get the rest of the UI out of the way.
  2. Provide quick access: as much as possible, give the developer access to the common Build actions.
  3. Consider mobile first: make sure that anything you can do on the desktop you can do on a mobile phone (if it’s possible and relevant, of course)
  4. Look familiar: with our new users coming from two primary sources, we wanted to bridge the visual language of PhoneGap.com and Adobe’s web tools. However, given that we are still between two worlds and have limited time and resources, we didn’t want to handcuff ourselves yet into looking “the same”.

So, with those principles in mind, let’s look at how we set about accomplishing our goals using the stated design principles by analyzing the Apps index page and detail page.

The Apps index page

The new apps index page

1. Establish a clear visual priority

On the apps index page, the most important information is the status of your builds - specifically, you want to know if something is ready to download or has failed. This is something I believe we communicated well in the old design and continue to in the new design. The one major difference is that the visual priority of a “completed” state is lower; it’s still distinct from the “pending” state of a build, but affords more visual priority to the error states of a build.

2. Provide quick access

The new design provides quick access to the “update”, “rebuild” and “debug” actions, and access to the QR code which allows you to install / upgrade from the index page as well.

3. Consider mobile first

The new apps index page

As you can see, the most important information for you as a developer - the build status - is still clearly visible in this state. The smaller screen real-estate of course demands a careful balance between providing critical information and overloading the UI. You might be saying “Wait - I can’t do everything on my phone from this page that I could on my desktop or tablet!” That’s true, but we didn’t say there had to be page-to-page parity. From your phone, you still have to navigate to an app’s detail page to get access to the admin functions. A little bit of progressive disclosure never hurt anybody.

4. Look familiar

This principle is tougher to quantify, of course, but if you check out the new PhoneGap.com and also look at an Adobe web offering like CreativeCloud.com, hopefully you’ll pick up on the similarities. Things like button and form input styles, specific colour values and certain interactions will differ between the three sites, but we feel we’ve landed at a nice compromise. Here’s a visual aid:

Three amigos

Three peas in a pod, ain’t they.

The Apps detail page

The new apps detail page

1. Establish a clear visual priority.

I don’t think I need to spend too many words here: the emphasis is still on build status, but this time with more information.

2. Provide quick access

The app detail page now includes all of the former app edit page functionality. In fact, there is no longer a separate edit page at all. You have access to all admin functions (even on your phone) including editing the settings, adding collaborators, and adding/editing signing keys. We’ve also replaced all of the model dialogues with “flyouts” that don’t block access to anything else on the screen and are a bit more mobile friendly. Protip: the ‘esc’ key dismisses them.

3. Consider mobile first

The only thing that we hide on mobile phones on this page is the QR code. Nuff said.

4. Look familiar

I don’t feel like I need to repeat myself … but it looks familiar, I hope.

BuildBot Rises

So there you have it. I hope that you agree with our principles and like the resulting redesign. Of course, if you see something that you feel violates those principles, hold us to them! We have a small team and we rely on your vocal participation to make this product better.

There are still bound to be a few hiccups, but keep in mind that we haven’t left beta yet and we cranked this sucker out in just over 4 weeks with a team of 1. The squeeky wheel gets the grease, so if you raise a fuss on GetSatisfaction about something we’ll be motivated to improve it sooner.

Aside from that, enjoy the new look and expect some more new stuff soon.