All Posts in app

July 22, 2014 - Comments Off on Useful apps in Brazil — Talkback Tuesday

Useful apps in Brazil — Talkback Tuesday

"Talk Back Tuesdays" is an original weekly installment where a team member of The Mechanism is asked one question pertaining to digital design, inspiration, and experience. The Q&A will be featured here on The Mechanism Blog as well as on The Mechanism's Facebook, Twitter, and Instagram, every Tuesday. Feel free to offer up your 2¢ in the comments.

George Brassey, The Mechanism's lead developer, recently returned from a 2 week trip to Brazil for the World Cup. His trip as a whole sounds like it was quite an unreal experience, but we wanted to know a little bit more about his #DigitalExperience while visiting an unfamiliar country.

Q: What iphone/android app did you use most this past week, and why?

With regard to my digital experience in Brazil, I wanted to talk about a few apps that I found useful.

1: Splitwise

Going on a trip with friends means there are going to be loads of shared expenses and it can be a headache keeping track of all these, especially when dealing with a foreign currency. Luckily for us, we had an app called Splitwise, whose purpose is to solve this exact problem. You register a group of those travelling with you and from there it is easy to add individual expenses, choose who is contributing and how much they are contributing. At the end of your trip you can settle up and Splitwise will do all the math for you so there are as few transactions as necessary. It also has support for multiple currencies, as well as an option for shared living expenses (e.g. roommates).

2: Google Photospheres

In a picturesque country like Brazil, there are many views that are impossible to capture in a photo. When you are surrounded by stunning scenery, Google Android has a great addition to their photos app that lets you capture a full 360° image. It takes a little patience as you stitch together multiple images, however it is easy to do and once complete you get an image that can be explored by tilting and twisting your phone to see every angle. You can even upload these efforts to be approved and added to Google maps.

3: Whatsapp

The sensational news of Whatsapp being bought by Facebook for $19 billion surprised many and while we in America often stick to regular SMS text messages, relegating Whatsapp to communication with friends who are abroad, in Brazil, as in many countries, people use Whatsapp as their primary messaging tool. By avoiding the cost of SMS messaging, Whatsapp, which is available on every phone smart enough to load an app (which isn't very smart), has incredible potential to become the world’s most popular messaging platform. For those travelling, this means one seamless experience for communication with friends all over the world.

George is a dauntless developer with a keen eye for user experience. The conceptualization of his work is informed by an insightful empathy for the end user. Check out his bio here.

Stay tuned for next week's "Talk Back Tuesday" when we ask Dhruv Mehrotra, a highly skilled developer of The Mechanism, about his own #DigitalExperiences.

Published by: georgebrassey in Government, The Internal Mechanism
Tags: , , ,

January 4, 2012 - Comments Off on Starting Mobile Web Development

Starting Mobile Web Development

We recently underwent the process of making our site mobile and tablet friendly. The results look fantastic but our implementation has, in places, been a bit cumbersome since the original site was not laid out with such an adaptation in mind. Now that we're more or less done I felt it would be pertinent to create a list or useful resources found and lessons learned along the way. Since this entire branch of web development is still so young and liquid I don't know how long the following will be useful but I hope it helps those as lost as I was when we began this trek.

Adapt or Leave?

One of the biggest questions when faced with the prospect of creating a mobile site is "Should my site adapt or redirect?" Unfortunately I don't believe there is one right answer to such a question since, like so much in life, it depends!

Some key factors that might affect our decision include the functionality we want, type of content we mean to serve and look/feel of our design. Is it important that our mobile version have stunningly different design and/or app-like animation effects? Then a redirect is probably in order. Are we mainly trying to provide a mobile version of a news, blog or other site where content is the focus? Then a media query adaptation would be beneficial as we make it easier for users to share content between devices (and keep all that traffic in one place to boot). However both options can be adapted either way if we put in enough work.

Let's not forget the last option: making a web app. Using services like PhoneGap we can take a our HTML and make it into a bonafide app on the user's device...well it's really just a virtualized webpage with greater device integration (accelerometer, media, camera, etc.)  and a dedicated icon on the device but sometimes that can be a great branding edge. And there's the added bonus that users can then use our "site" even when not connected to the internet though the line between website and app begins to blur at this point. A direct migration of your website to an app will probably never clear the iTunes store's strict approval process so we need to add something unique which may  be more trouble than its worth.

Let Me Pose You a Query Sir

Media Queries: confusing, under-documented, cutting-edge, useful as all hell and bloody confusing! It took me awhile to get my head around these little statements of goodness. Once I did I came to understand their power and structure. We have two main options when dealing with media queries; we can use them to specify certain CSS links or alternatively we can write them into an existing CSS file. Personally I used a mix. It made sense to use the internal CSS version when altering this blog's WordPress theme while on the other hand the link option made sense for most other pages. In general I'd  recommend the linking option since it keeps each CSS shorter, allows for easier document navigation and generally keeps our process cleaner.

It's easiest to think of media queries as giant "If" statements that inject our extra CSS when our given properties are met. As such, we must remember to override existing styles in order to apply our new device-friendly ones. It can be tedious searching through our original CSS file to see which specific properties need to be overwritten. I found it easiest to simply copy the entire original CSS, do all changes as required and then go through and delete any definitions or properties that remained constant (I sniff an extremely useful code highlighting/SVN tool that could do this comparison automatically along the liens of CSSlint).

Another nice benefit of media queries is the ease of testing and updating them. During the development process, make sure to specify "max/min-width/height" AND "max/min-device-width/height." This will ensure that our queries appear not only devices with the specified resolution but also any similar window viewport allowing us to use Firebug/Chrome Inspector as we normally do for a familiar debug cycle as well as useful previewing tools like Protofluid. Just remember that once the site is live, we should only target devices if we don't want adaptive versions appearing on desktop browser windows of the required size as was our case since the mobile versions or so device specific.

Quite Novel

Don't forget this is a completely new ballgame. Using media queries, especially with mobile devices, we can add all sorts of fun and/or hidden functionality into a site. How about a site that literally changes personality the smaller the window? Maybe you have a logo or character that actually reacts to the changing amount of space they're given as elements shift about them? And don't be afraid to think even more radically. The very function of a page could alter depending on a devices orientation. We could have our copy appear in portrait and then an image gallery appear in landscape (as is the case for our iPad site). Such novel use of media queries can completely redefine how people interact with a site and help redraw the front lines of the ongoing war between app and webpage.

No touchy

Of course not all the changes that come out of these new device are solely good. In fact the biggest one requires a fundamental change in how we think about design and interaction: touch. No cursor means no hover. Truly though, hover is simply an artifact of the invention of the mouse, itself not very old and clearly diminishing in importance. There's now a new frontier of interaction and design patterns to be explored.

Here though, the waters are still quite murky. Some plugins, like this jQTouch one, allow a webpage to respond to touch-specific events that most browsers and libraries don't yet natively handle. Of course this comes with the down side that we also lose our native touch-to-scroll ability (though theoretically we could reconstitute this functionality by hand or via work-arounds). For sites designed specifically for small screen devices this opens up many new possibilities that before only existed natively in apps and not on the browser.

Real Estate

One clear limitation we have on mobile devices is the lack of real estate. Design is all about creating something to fit within certain restrictions which are quite tight in this case. However good design often comes out of such challenges so the news isn't all bad. Sadly problems arise since lack of space also reduces our margin of error. When designing a website for the browser, we can safely assume that most screens will fit a design of a specific minimum height and width with room to spare or allow the user to easily scroll about the page to see everything.

Alas the fragmented nature of the mobile market, even if we disregard tablets, poses greater challenges since different devices not only have a wide range of sizes and screen ratios but also numerous different abilities and native elements. As such we must be dead certain that our site is adaptive to many heights, widths and especially devices. Yet by in large the best mobile sites are designed to fill the screen perfectly so making adaptive designs can be difficult to impossible. Perhaps this is where "good enough" is fine since the prospect of specifying designs for each resolution is daunting to say the least. Furthermore, we can try and maximize our real estate by hiding browser elements when possible. For instance many mobile sites "hide" the address bar on mobile Safari by programmatically scrolling the page down by the bar's height giving us more space above the fold.

If It Ain't Fixed

We've grown used to a lot of functionality on the web but many of these norms may not have been carried over to the mobile world, at least not yet. Some APIs may not yet have native support for our platform of choice but we can, on occasion, find workarounds like this one for the Google plusone button. However, sooner or later we have to simply cut functionality from our mobile site and sometimes this may be for the best considering the restrictions and problems discussed so far. So if you're wasting time trying to get a certain resource to function on your mobile site when you could be perfecting the design itself or, better yet, device testing, consider simply hiding that element or simplifying the functionality. After all, even if you get it to work it's only a matter of time until official support rolls out and your work's left out in the cold.

References
  • Smashing Magazine Intro Tutorial
  • Less useful Adobe Tutorial but with great list of possible properties
  • ProtoFluid is a great way to test out your Media Queries. It essentially creates a iFrame of a given URL with dimensions specified by the chosen device. I found it to be a bit unstable and often designs look different on the actual device. There is also the lack of scroll/touch, the persistence of hover states and other Desktop-Device hybrid funniness but its great for checking your initial layout. BE SURE TO TEST ON DEVICES AS WELL!!! (Note: since Protofluid works via Desktop browser, make sure all your queries specify "width" and "device-width" as outlined above)
  • Hide address bar in iOS mobile Safari
  • Google+ plusone mobile button fix

Published by: benchirlin in The Programming Mechanism
Tags: , , , ,