FOLLOW OUR BLOG
- April 2014
- February 2014
- January 2014
- November 2013
- October 2013
- September 2013
- August 2013
- June 2013
- May 2013
- April 2013
- March 2013
- February 2013
- January 2013
- December 2012
- November 2012
- October 2012
- September 2012
- August 2012
- June 2012
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- December 2011
- November 2011
- October 2011
- September 2011
- August 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- December 2010
- November 2010
- October 2010
- September 2010
- July 2010
- June 2010
- April 2010
- October 2009
- May 2009
- April 2009
- March 2009
- February 2009
- July 2007
When dealing with large amounts of data—especially text heavy data— there are several techniques you can use to interact with this data.
First we have to talk about where the content can live. It can be:
- All on a single page – and hide and show parts as necessary.
- All on different pages – tied together in different ways.
- As snippets/separate files – pulled into one page.
These are some of the ways you can show large data sets:
Used on mobile devices, navigation that slides as you drill down.
See it on the Boart Longyear site › (be sure to view on a mobile device)
An intro and an image to help the user know they are in the right place.
Clicking the center tile zooms into this:
Things to Remember When Choosing Techniques
There are a lot of really cool animations and techniques out there. Finding the most elegant solution comes from restraint and considering both the end users and the content creators. You want to make sure your end users feels like things are intuitive, out of the way and aren’t flying around all over the place. You want to make sure that content creators can easily support the chosen techniques and don’t find it to be too finicky or full of fiddly bits.
Sometimes it’s ok to display a “how to use this app/site” to your users. This should be minimal and only when a user will interact multiple times with your content. If you are building a simple display website there is no need for a user to learn to use it. The same thing when you go to a chain restaurant and they want to know if you’ve been in before and if you know how the menu works. Menus should be pretty straight forward, so should your site unless you have an engaged audience.
Here are a couple examples of ‘how to use’ instructions:
Martha Stewart Living iPad Edition*
Evernote iPad Edition*
The Touch Screen Aspect
The thing to remember with these techniques is how they will work on a touch screen (mobile and tablet devices). Hover will not work – so hover for flyouts and others needs to be converted to clicks. Touch screens have the added ability of multi touch gestures. Large data displays on touch screens is a topic for another day.
Which Technique is right for your page?
Choosing the appropriate technique can only be done once a representational set of the content is put together. Understanding the relationships the content has, how it’s digested and how it’s managed are all key to choosing a data display strategy. This presents the age old problem of having content before or concurrently with design. That’s why building a site is sometimes like jumping out of an airplane and assembling your parachute on the way down.
* All examples in this post were developed by Sawaya Consulting unless noted with an asterisk.
Look what I have wrought with my laser! In between projects we’ve been doing a lot of Halloween crafting around the place. When we got our laser last year these were *THE* projects I wanted to do with it.
I’ll post the other ones coming soon, but today I wanted to share the invites to our party.
These custom tombstones have each person’s name on them, the party details (blurred out our address, don’t get crazy on me, internet) and there are seven different backs.
Laser Geek Talk
For those of you with a similar laser that happen upon this, here are the ins and outs of this particular project.
- I used gray flannel (color) mat board with a black core. The black core stuff seems to char and smoke up more than the lighter cores.
- These are rastered on the front and back and then cut out with the laser. The cutouts left char marks that got all over everything so I stacked them together, weighted the stack and sprayed the edges with Clear Matte Fixative. I then did the fronts for good measure.
- These took 1.5 hours for each run of three (that’s the max number that fit in the laser at once). The backs took 15 minutes each.
- These mail as a standard postcard except they are slightly over the 1 ounce limit and needed additional postage (66¢).
- I set my designs in black and then an outline in yellow. I turned off the black for the vector and the yellow was too light to show up on the raster screen.
- My settings for this project were: Raster 100% power / 70% speed; Vector 80% power; 60% speed.
When we slid into the mobile app game everyone was still trying to figure out the best solution (hey, it’s an evolving sport even today). Since then we’ve built native apps, HTML5 apps, shell apps, responsive websites, mobile sites that compliment the full site. We even wrote the book on it to help clients figure it out.
It’s funny when you start to talk mobile strategy—seems like everyone has a really strong opinion. I was talking to someone the other day that was so anti-native and so pro-HTML5 I could barely get a word in edgewise.
Our really strong opinion is that you have to choose the right strategy for the project, no reason to put a stake in the ground and declare your position across the board.
Different Mobile Strategies Explained
Let’s look at what we’re talking about here:
- Native App: An app built to run on a specific platform (iOS which runs on iPhone/iPad/iPod, Android, Windows Phone).
- Pros: Works really well on the specific device; can access device features like the camera, contacts and email; can work offline; is easy for users to get from an app store; easy to charge money for the app.
- Cons: Expensive to build; has to be redesigned slightly and redeveloped completely for additional platforms.
- HTML5 App: Also called a web app, uses new web technology (HTML5, CSS3, jQuery) to produce a product that looks and functions almost identically to a native app.
- Pros: Design and develop once to hit every platform, even the ones with smaller market shares like BlackBerry; can be developed by a traditional web developer instead of finding a specialist; easy to push updates anytime; best bang for the buck if you can sacrifice certain features.
- Cons: Difficult to charge money for; some users will have a difficult time “installing” it (saving it to their devices homescreen); cannot access some device features; can be slower than a native app.
- Shell App: An app that uses HTML5 or another kind of programming language that is then wrapped with a piece of software (PhoneGap, Appcelorator) to function like a native app and be released via the app stores.
- Pros: Develop one app and release on multiple platforms.
- Cons: Hybrid apps don’t always look right cross platform—iOS has very specific design patterns that are different from Android and vis versa; many developers find they spend as much time trying to learn yet another system as it would take to do it natively; many people find that they are just not quite right. As of yet, this isn’t a course we recommend taking, although it has a lot of promise.
- Responsive Website: A website that changes layout depending on what device you use. The website uses the same HTML5 code and then controls the display with CSS3.
- Pros: Works well on a variety of devices and platforms; the only strategy presented that includes a view for a traditional desktop/laptop as well as mobile and tablet; easy to keep all views in sync so there is only one place to update code.
- Cons: Can be expensive to build if it’s not truly needed (some designers/developers are pushing for always including a responsive site—great idea if your client has the budget); needs to be really well thought through to decide what is dropped on the mobile view versus the desktop view to make sure each experience is complete and not just a crummy fail over.
- Separate Mobile Site: A site that compliments the regular website, but is developed to be completely separate.
- Pros: Works exactly as intended on the mobile view; can be designed/developed to use the same content as the main site (so there aren’t multiple places to update things); can be a cheap and easy add on to an existing website without touching the current code.
- Cons: Even though you can use the same content, it’s a different set of code so if something major (like the logo) changes it will need to be updated in multiple places; it is not as complete in the information as the complete site and often includes a “view full site” button.
Different Mobile Strategies in Action
We built this app natively for Boart Longyear. Why: This app is used on tradeshow floors where there often isn’t internet available; the app connects to the device’s camera to scan codes and pull up the related information.
We built this app using HTML5 for Boart Longyear’s Drillers Connect. Why: This app is used all over the world, most workers in the field will use an Android or iPhone to access the information, but some will look it up on a desktop.
Despite our best efforts to use Dreamweaver/PhoneGap we just cannot get an app to come out and install on the other side.
We built this website to be fully responsive. Why: Each view had to have full access to the entire site. Many people search for their next job while on their lunch break at their current job, and they do with a mobile/tablet device. To include the same information on something as small as a phone or tablet we shortened the logo and introduced alternate navigation.
Separate Mobile Site
We added this site onto the current Chow Truck website, we also have two more of these in the works. Why: There are very few businesses that we would recommend doing this for — but a restaurant, especially one that is in a different place every day—is going to see the most traffic from mobile phones. When you are in the car, on your phone there are very few things you want to know: where the place is, if they are open and what’s on the menu. About us, history, news, awards, etc are not as urgently important. Plus, we’ve recently learned that Open Table strongly encourages restaurants to have a mobile site and menu.
The Future of Mobile Strategies
Mobile strategies are evolving quickly. We look forward to the day that a shell app or good HTML5 to native wrapper works well, native apps are expensive—but in the right light give the proper ROI (anyone else taken out a second mortgage to support a Candy Crush habit?). We were fully onboard thinking that everyone needs a responsive component, but then we looked at the additional design/development and realized a lot of smaller clients are good with a single target site—as long as that site still works on a mobile it doesn’t have to exactly fit the mobile.
What are your experiences, either as a consumer or site owner with different mobile strategies?
I was going to use one of these book covers for my first book, some of you even helped by voting on them. In the end, even though they were clever, they were scrapped for a design that allows you to read the entire title from the Amazon thumbnail image.
I’m posting them here for reference on a future post about how to publish a book.
I’ve been updating several websites lately and focusing on cleaning up titles and adding meta descriptions. This was all kicked off when I rebuilt www.buildingamobileapp.com to take advantage of Google Author Rank and rich snippets. So now when you search for “building a mobile app” you’ll see my face next to my site.
2013 Best Practices for Webpage Titles
- Make your titles descriptive, include your brand name, but separate them with delimiters like a hyphen, colon or pipe.
- Make sure every page on your site follows the same protocol. You can set this up to work in WordPress, or do it by hand on a small site.
- See Google Webmaster Tools Reference Article ›
2013 Best Practices for Meta Descriptions
Below the title in your HTML you should add a Meta Description (please note, these are different than Meta Tags). This is a short sentence about each page that describes the PAGE, not the site.
You use code that looks like this:
<meta name=”description” content=”We serve only the best, high-quality, fresh ingredients prepared in authentic Middle Eastern style. We also have vegan, vegetarian and gluten-free options.”>
Before & After
So, does it work, does it matter? Originally on the Mazza website I had a whole bunch of different titles, like:
- Mazza Middle Eastern Cuisine – Menu
- Locations & Reservations – Mazza
See, I didn’t have a pattern, I just put whatever. I also had no meta descriptions, so the text under the title looked like an unholy mess when you searched for “mazza cafe”:
The screen shot above was taken on February 7,2013.
I went through and put in titles that all follow the same protocol:
- Dinner Menu | Mazza Middle Eastern Cuisine
- Locations | Mazza Middle Eastern Cuisine
- Reservations | Mazza Middle Eastern Cuisine
I also added meta descriptions to each page, like:
- We serve only the best, high-quality, fresh ingredients prepared in authentic Middle Eastern style. We also have vegan, vegetarian and gluten free options.
- Mazza Middle Eastern Cuisine has two locations to serve you, 9th & 9th and 15th & 15th.
- Mazza Middle Eastern Cuisine now accepts reservations at both locations through Open Table.
So what does the search for the same term return a couple weeks later on February 22? This magnificent view:
I think my meta descriptions are too long, and I also think I can drop the brand name (Mazza Middle Eastern Cuisine) from them. All in all though, I’m very happy to see that in a couple short weeks the search experience is much cleaner.