GigBeat Design Decision 4: Empty Screens

This is a series of short articles, highlighting some of the design decision behind GigBeat 1.2.

GigBeat Design Decision 1: Event screen

GigBeat Design Decision 2: ICS

GigBeat Design Decision 3: Tablet UI

GigBeat aggregates lots of information that comes from various sources like Songkick, Last.fm or even our own Base. Some of those pieces of information depend on an account or an active internet connection. Since we want to keep GigBeat free from a forced login to a certain network, we had to deal with empty screens and unavailable data, eventually. 

We missed the opportunity to get those screens right with the first release of GigBeat 1.0. So we wanted to make things better this time. Having users take certain actions before they can use the core functions of an app is always wrong. People don’t want to deal with setups, tutorials or long explanations - they want to dive right into the fun as fast as possible. This is especially true for mobile apps, since tasks need to be completed quickly on the go. Unfortunately sometimes there is just no way around a login or an important setting to display the data you want to show. In such a case, explain shortly why this is important, and give fast and easy access to that particular setting.

Even better: Don’t break the experience. If your app is colorful and fun, keep the empty screens colorful and fun. If it is simple and streamlined, keep it that way. Try to hold up that new excitement throughout the process, even though there is no real content to be excited about, yet.

When going for the location screen in GigBeat 1.0, you had to type in a city or hit the nearby-icon at the top to get something to work with. GigBeat 1.2 scans and returns all nearby cities right away, so you can star your favorite locations or dive right into your local gigs. No need for an empty screen.

Other screens with no immediate data like recommendations or upcoming gigs are covered with small illustrations, an explanation and a button to get right to the settings or suggest content. This is even more fun on a large tablet screen, where we found the space to insert a couple of (obvious) hints.

There’s still a lot of room for improvements. I’ll keep you posted.

2 months ago  /  0 notes

GigBeat Design Decision 3: Tablet UI

This is a series of short articles, highlighting some of the design decision behind GigBeat 1.2.

GigBeat Design Decision 1: Event screen

GigBeat Design Decision 2: ICS

Not long after GigBeat 1.0 was released, a handful of people asked if we were planing on a dedicated tablet version. 

We were brainstorming a little about this, and decided against it. Not only did we have a lot more important things to do, it just didn’t made any sense to us. We’re using our phones to do short, standalone tasks while on the go. Exactly how you take a couple of minutes off to look for interesting gigs around. Our tablets are used for exactly the opposite: We use them to waste time on a couch, sometimes several hours at once. So just looking up a close live event seemed pointless on a bigger screen. 

Introducing artist information, music and videos to GigBeat 1.2 changed that. GigBeat wasn’t only about dates and names anymore, it was about content. And everybody who spends hours and hours on Bandcamp, Google Music, iTunes, you name it, knows how fun it is to search and listen for new interesting artists.

So we decided to create that tablet version. Now what? Just displaying all those lists side by side would not cut it. Introducing all those big band pictures came in handy, but we had to rework all the content to fit nicely on the large screen. Using lots of grids, sidebars and sliders should be the way to work with all those Android tablet sizes, landscape and portrait modes. We spent quite some time with sketches, wireframes, and even paper prototypes, to get the layouts right.

The dashboard felt like a challenge at first. Just displaying 4 icons on a large screen seemed like a complete waste of space. Luckily the redesign of the Featured screen was already under heavy development. We wanted to introduce featured artists, popular and new ones, and some staff picks to round out the personal experience. So now you can dive right into the content when launching GigBeat for tablets.

Be patient, though. GigBeat 1.2 glory with tablet support will be unleashed to you couch potatoes soon.

2 months ago  /  1 note

GigBeat Design Decision 2: ICS

This is a series of short articles, highlighting some of the design decision behind GigBeat 1.2.

GigBeat Design Decision 1: Event screen

Android 4.0 introduced a whole new design language. Almost everything about the operating system got reworked somehow. If you’re really ambitious about an application, you want to make sure that it feels perfectly in place with all the other native apps. 

We wanted to make sure that GigBeat works and looks perfectly on Ice Cream Sandwich devices, as soon as the OS was introduced. But at that time, there were no official guidelines available, so we had to figure it out by ourselves. 

Taking a good look at screenshots and playing around with the available devices (that being the Galaxy Nexus exclusively in early December), there were a couple of important design decision to be noticed: Ice Cream Sandwich used almost no gradients. Instead plain color is presented everywhere. Actually this is a pretty smart move, because plain colors don’t need assets to be created, and they scale a lot better over all sizes and orientation.

Also most UI elements are rectangular, sharp and straight. You won’t find a lot of round corners, smoothed out edges or bevels. Everything feels very geometrical and futuristic. This also translates to the icons.

We embraced all the new design guidelines quickly. Unfortunately it turned out that we had to rework probably every screen and every interaction element of GigBeat. I started out by taking screenshots of every single screen of GigBeat, layed them out as a logical pattern, and added notes to each screen, what to change for ICS. Gradients became striped patterns, icons became flat and rough, and we ramped up all assets to xhdpi sizes.

A quite special case was the new band profile. We needed a nice layout to showcase tourdates and artist information side by side, without prioritizing one and burying it behind an interaction. The solution of ICS’s People app seemed perfect for the app. But the problem there was a lack of support for all devices prior to Android 4.0. Long story short - Mike Novak got it running all across the board. Pretty sue he’ll give you n update on this eventually.

Moving the whole app’s look and feel over to Android 4.0 meant a lot of work for us, but in the end absolutely worth it. All the decisions gone into it scale very nicely across all kinds of devices. The appearance feels clean and fresh and distinguishes clearly from other mobile operating systems. Finally GigBeat is ready to roll on the next generation of Android devices.

Lucky you. A couple of weeks ago, Google published the first comprehensive Android Design guide http://developer.android.com/design/index.html. I would highly encourage every designer or developer to work through this document, no matter how good he thinks he knows Android. But remember - these are just guidelines - If you find a solution that solves a problem even better, go for it. 

2 months ago  /  1 note

GigBeat Design Decision 1: Event screen

This is a series of short articles, highlighting some of the design decision behind GigBeat 1.2.

When we released the first version of GigBeat in early September 2011, we didn’t expect a lot of interest in the app. And why should we? There were similar apps out there. But those didn’t felt right to us, somehow.

We spent a lot of time figuring out how we approach searching for good live events. Artists, locations, favorites, comfort. All were taken into consideration. We used our free time to create a couple of working lists of content, that were linked together similar to our existing mindset. At the end we gave GigBeat a name, a logo, some color, thumbnails and icons and shipped it. We never thought too much about the visual experienced and aesthetics in the first place. When revisiting the UI for 1.2, the first thing we noticed was that we were able to find interesting gigs all around. But a live concert might be one of the most exciting thing that can happen to anybody on a regular basis. In GigBeat 1.0 that event screen was just a long list of text. Not too exciting. Every live event consists of three parts: The date (do I have time?), one or more artists (do I know/like these guys?) and a location (is it worth the traveling?). There are other factors revolving around a gig, like tickets, directions and people going, but those are secondary in nature.

So we created that new event screen with a strong hierarchy around the most exciting part: The artists. Big, bright pictures generate much more excitement than just small thumbnails and monochrome icons. Wrapped between the date with the calendar option and the location, including navigation and checking, felt just right. And if only two artists are playing, there’s even some room for wishes ;-)

2 months ago  /  2 notes

Gigbeat 1.2 - A look into tablet development

As the third day at Mobile World Congress comes to a close it is time to share some info on the tablet launch for Gigbeat.

Early on we decided it was smart to adopt the fragments API for Android even though we knew that we weren’t ready to release a full tablet version of Gigbeat. The tablet screen has tons of real estate and we didn’t feel we really had the content to make the experience great for the user. 

With the addition of artist bios, songs, videos, and links we realized this could be the perfect platform for discovering new artists while browsing around on the tablet. Even though we release the beta version containing tablet support, we are still refining our user interface to really take advantage of both the 10” tablet screen and the 7” tablet screen. The two sizes are different enough where it might make sense to layout content in a slightly different manner. When you look at the default orientation for most 10” inch tablets you’ll notice it is landscape. however, for most (if not all *don’t quote me on it) the 7” tablets have a portrait orientation by default. This definitely has made us think about what makes sense for each screen.

Many developers have been complaining that there’s so many different screen sizes to support that it really adds a lot to the development process. While yes it is obviously more work to support the various devices, developers should really look at it from the perspective of more users. One of the main reasons Android is attractive to users is the variety and finding a device that suits their use cases. In most cases this is really just user interface tweaks and making sure the right information is displayed the right way depending on the screen. For Gigbeat, none of the actual program logic really needed a change and we were able to get up and running with a beta version for the tablet very quickly. 

I would encourage developers to really take a strong interest in delivering the best possible experience to as many users as possible. Just because something is just a little bit more work isn’t really a great excuse to just shut users out. Yes, in certain cases there are limitations to what certain devices can run. Overall though if your app can support a particular device I feel it is certainly worth taking the time to make it right.

Have a look at a couple of tablet screenshots for Gigbeat 1.2 and don’t forget to give the beta a spin. Let us know what you think!

Beta: http://gigbe.at/mwc

3 months ago  /  0 notes

Gigbeat 1.2 - Beta

From the development side this wasn’t a simple solution to implement. We had a look at the source code for the People app and noticed that the views relied on several ICS APIs. This presented a slight problem for us as our app supports users running Android 2.1 through Android 4.0. We decided this user experience felt too right to just give up on and so we set out to port this great widget back to previous versions of Android.

This brings us to the second piece of exciting news. We have decided we are going to release this carousel widget as an open source Android library project so other applications can easily can enhance their user experience in the same way we were able to. We have a little bit more cleaning up to do but you should expect to see the source code available in the next couple of weeks.

With the release of version 1.2 comes an optimized version of the application for tablets. We are excited to finally have an experience that can be enjoyed on the large display! Check back tomorrow for a detailed post on the tablet interface for Gigbeat 1.2

We hope everyone is as excited about the new changes as we are. We ask everyone to remember that we are releasing version 1.2 as a beta. We decided to do it this way because there’s still some rough edges to iron out and I’m sure bugs to fix, but we greatly appreciate our user’s feedback and would love to hear what everyone thinks of the new version. If you have any issues to report while using the beta please send over an email to support@gigbeat.fm. Link to the beta below!

http://gigbe.at/mwc

Thanks!

3 months ago  /  1 note

Another GigBeat 1.2 Preview

We just love Android. We also love big tablet screens for wasting time on our couches. But to be honest, there aren’t too many really satisfying apps out there that make good use of the big screen. It’s about time we change that. We will be revealing GigBeat 1.2 with tablet support at MWC. Here’s another sketch, to tease you a little bit more.

3 months ago  /  0 notes

GigBeat 1.2 Preview

3 months ago  /  2 notes

Mobile World Congress

3 months ago  /  0 notes