More information on knockout is available from http://knockoutjs.com/

Some Highlights from Last Night

Native apps vs web apps

Many native mobile apps are built the same way websites were built in the 1990s: a patchwork grid of sliced images butted up and layered over one another. Since a native app can load all of its assets on your device via the initial download, it can get away with using a lot of rasterized graphics. A web app will try to minimize the number of images it uses, however, since they’re downloaded upon the first visits to any of the pages. To minimize the load, and generally provide site flexibility, many assets are built on-the-fly using CSS.

Modern CSS can produce gradients, drop shadows, inner shadows, rounded corners, and all manner of text effects. There are certainly more sophisticated effects you can only get by including an image, but many can be built on the browser end. A web developer will typically only pull the assets he absolutely needs from a PSD, and build the rest from scratch as best as he can. The more CSS is on a page, the more easily a visual can be changed, as it’s mere keystrokes rather than the production and insertion of a new image asset.

CSS can be interpreted by devices in a variety of ways. It’s natural for simple things like the darkness of shadows, the way a rounded corner renders, or the line-height of text to vary slightly from device to device. It’s rare that a user will visit a site across several devices with distinct rendering engines, though, so as long as the site doesn’t look broken, these little differences are entirely unnoticeable. Effort will be made by the developer to achieve parity, but in some instances the spirit of a design may be targeted in lieu of its exact specification.

The older a device is, however, the less likely it is that it’ll support the entirety of the CSS spec. Accordingly, certain design patterns don’t necessarily translate to a web app the same way they translate to a native one. One common issue is the lack of support for fixed-position background images, which when paired with poor support for HTML containers that scroll their internal content (a fixed-position background workaround), results in fixed-position backgrounds just not being possible in web apps. There are device and browser pairings that indeed produce the desired effect, but they regrettably don’t comprise the vast majority of the devices on the marketplace.

Two important concepts in web development are those of progressive enhancement and graceful degradation. They imply a website that can look progressively nicer in newer web browsers, and one that degrades in older web browsers without ever feeling broken, ugly, or non-functional. While developing a native mobile app, the design is typically always the design, and will appear the same across devices. A web app, however, will often vary from device to device, depending upon the abilities of that device’s web rendering engine. Accordingly, a design heavy in CSS gradients, shadows, and rounded corners may end up looking much flatter and pointier on, say, an ancient Android (or Windows Mobile) device. Sometimes only visual niceties will need to degrade, but other times the site may actually become less functional, such as pinned headers or footers no longer pinning correctly. These things will need to be understood when the design is being built, so that when certain items need to degrade on older devices, they degrade in a fashion that does not negatively impact the overall experience.

It’s also important to remember that a web app is just a website. By running in a web browser, it will generally not perform with the kind of smoothness and snappiness you’d get from a native app. Web code is hugely more maintainable and deployable, but the environment it runs in limits its ability to emulate a native experience exactly. JavaScript can be used judiciously to try and produce certain effects, but it can only go so far. This is especially true on older devices, where hardware acceleration is not an option, and CSS animations offer few benefits.

When building a “hybrid” app, which combines web code and native containers, you can get around some of these issues. For example, a native shell can have a fixed-position background image, while a web view can layer on top of it, producing the desired effect. The native shell can also handle all page transitions and layer in some native effects, producing a much smoother and more “native” feeling experience, while the actual components of the page are still web views. There are varying degrees of hybrid integration, where the more basic options merely load a website from a live server in a native shell, and more complicated ones integrate web code directly, and serve it up in the initial download package from an app store. Which approach is more appropriate depends ultimately upon the kind of product being produced.

Extracting assets

Whether or not a developer can parse a PSD and pull out assets will vary from person to person. In most cases the developer can grab what they need, but there are some instances where it becomes much more difficult, depending upon how the PSD was built.

Sometimes an image, usually an icon for a button or something similar, will have various background detritus around its edges that gets hidden via layer blending. This makes it nigh-on impossible for a developer to get the image with a proper transparent background. Layer blending to remove backgrounds is fine for elements that will be locked to their backgrounds when they’re sliced, but if the developer wants only the icon so he can build the background via CSS, make sure that the icon is clean and accessible for slicing by itself.

There are also cases where a PSD has a semi-transparent element, maybe a gradient, that the developer will want to reproduce via CSS. It can be difficult to sample the correct colors, or figure out the level of transparency, if the layer has been rasterized. If the effects are reversible, there’s no problem. If not, though, it would be helpful to provide a reference for which colors were there before they were made transparent, and what the opacity level is set at. Better yet: don’t rasterize, so that the developer can reverse-engineer an element to discover its source components.

Working with fonts

The latest CSS specifications support the inclusion of actual font files, rather than just relying on what a user already has installed on their machine. If you have a font file in the right format, it can be bundled with all of your web files and will load in the website like any other font. This gives a ton more flexibility in design, where one used to have to use images for any non-standard fonts.

That said, many fonts simply were not made for the web, or aren’t old enough that the web was built around them. A great example is Helvetica Neue, which is exceedingly common in modern designs built on Apple computers. It’s a font that isn’t present on Windows machines or Android devices, so it needs to be included via CSS in order to function. It wasn’t designed for web use, however, which means if you actually purchase the font and get it included, it may render very differently on non-Apple devices. Line-heights are the main culprit here, where trying to use a non-web-font across a variety of devices and operating systems will result in very different baselines, rendering the font largely useless in tight situations like navigations or buttons. Helvetica/Arial = good. Helvetica Neue = bad. If a font like that is only used in a loose callout location, though, where the exact line heights aren’t as important, it might still be okay to work with.

When choosing the base font used for the majority of elements on a page, web-safe fonts are highly recommended. There are a set of web-safe font groups that are present on pretty much any machine, and these should form the foundation of a site. If a non-standard look is desired, though, seek out fonts that were actually designed for use on the web. Adobe makes a ton (like Source Sans Pro), but you can also get a huge amount of free fonts via services like Google Web Fonts. When putting together a design from scratch, try to choose your fonts from a service like this (Typekit is another popular option), or generally stick to those fonts that will definitely work well on the web. CSS fonts don’t work in some older browsers, though, so a fallback font style should be chosen in those cases.

Overlooked deliverables

Websites are naturally fluid. Consider that your assets may need to stretch or smoothly elongate for different screen sizes or devices. Define rules for whether something should get bigger, get wider, move over, or just stay the same should the screen get larger or smaller.

Wireframes and information schematics are useful for communicating how a responsive design should perform, but they’re also useful for conveying how the user should be able to interact with the app, and this informs how the developer will build it. Annotated wireframes should accompany all but the most bare-bones designs, and highlight how each part of the design should move and react to input.

It can be helpful to have assets provided to the developer at both LDPI and HDPI resolutions, rather than the developer sizing down HDPI assets when he needs LDPI ones. There are instances where in the process of resizing, an un-rasterized image will resize its source components, but not effects (like shadows/strokes), so the lower res asset will actually end up half small and half big. But when the assets are rasterized together and then resized, the quality of some elements can suffer. The more of this that can be addressed during the design phase, the better. There’s no need to actually deliver the assets pre-sliced, but H/LDPI source documents where the designer has ensured that the assets have resized correctly would be ideal.

It’s often helpful to just have a chat with the developer to hash out exactly how the assets should be produced, since the project may allow for certain elements to be built entirely with CSS.

Desktop sites

Sometimes you’ll work on a traditional desktop web project, and in that case most of these rules still apply. Even a site designed for a larger and mouse-driven screen will be regularly accessed via mobile devices, and should accommodate those devices with a responsive design and touch-friendly elements. This includes not relying too heavily on mouse-exclusive interaction paradigms like mouseovers.

Desktop sites have slightly different challenges in terms of browser support, though, since the question of how to support older versions of Internet Explorer crops up, and while JavaScript is a given on a mobile device, there may be desktop devices that have it disabled. These issues still typically adhere to the concepts of progressive enhancement and graceful degradation, so the overall approach can be similar.

post by: Cory Faller

Captive audience.

post by: not Max Bare

VOKAL Custodial Enforcer, Bowser, monitors the grounds.

Some Mobile Makers students socializing.

 Mobile Makers Academy Winter ’13 represent! A nod to “Volley Pong” which is apparently something of legend.

For more info on Mobile Makers Academy or to apply for this coming semester’s iOS Immersive or iOS Accelerated Programs check out: http://mobilemakers.co/

post by: Max Bare

About Mobile Makers Academy: 
Interested in learning Mobile App development like a boss?  The Mobile Makers Academy is an Intensive training program teaching iOS development. They offer an Accelerated program for developers, and an Immersive program for beginners. Located here in Chicago Mobile Makers promises an atypical class structure  that simulates the working environment where students learn from the best in the field: instructors Don Bora, Adam Lupu, Brandon Passley and Adam Haun.

For more info or to apply for this coming semester’s iOS Immersive or iOS Accelerated Programs check out: http://mobilemakers.co/

Can’t leave without some Mobile Makers Merch!

VOKAL’s own Brian Flavin slingin mad serves.

All the while, secret Bomberman Tourneys raged on in the Bomberdome Bunker.  Courtesy of the Fergulator, the Dev team lined up to dethrone Bomberboy Bracken Spencer as champion. Eventually Cory the Combustion Kid reined victorious in a final triumphant battle.

Touching moments in the VOKAL family as our own Andy Mack congratulated as Ping Pong master…. until next time.

Vest days are the best days.

Soon our wonderful new offices will evolve from this…

…to this!

A couple of months ago I started working on a simple project using node.js and I wanted to write a post about the similarities and differences in functional programming between JavaScript and Objective-C. However, while I was writing that post I realized I did not truly understand functional programming. I could write blocks in Objective-C and I could write functions in JavaScript but the theory behind it was lost to me. That being said, I decided to dig deeper to understand not just what the code was accomplishing but why.

Functional Programming

Considering my background as an iOS developer, I’ll start with blocks. “A block is a section of code which is grouped together” – Wikipedia. In Objective-C, blocks are used to package up code allowing it to be called in any function on any thread. This is made possible using closures, which saves the state of the variables contained within the block for proper execution elsewhere. “Blocks are particular useful as a callback because the block carries both the code to be executed on callback and the data needed during that execution” – Apple. One example of this would be the new way of animating UIView transitions:

In this method, two blocks are passed in as parameters to execute at specific times. Doing it this way is much cleaner than the previous way of animating:

As you can see, it is much cleaner now using blocks as opposed to needing to set two methods and a delay to accomplish the same thing. Apple made it simple to pass the animation method: a function for the animations to perform, and a function for what to change upon completion. Blocks also do quite a bit for asynchronous programming in Objective-C as well, but we’ll get into that later.

Now moving on to functional programming in JavaScript. “JavaScript is a prototype-based scripting language that is dynamic, weakly typed and has first-class functions.” – Wikipedia It is a language used primarily for web development, both server side and client side. The three key functional components that JavaScript makes use of are first-class functions, nested functions, and closures. First-class functions are treated like variables, they can be passed as arguments, altered, and executed elsewhere in the code. Nested functions are defined inside of a function and are able to retain and use variables from the parent function. Closures, much like in Objective-C, saves the data located within a function so that it can be executed elsewhere while containing the current values of the variables.

In this example, the displayTotal function makes use of first-class functions and nested functions, and closures. Within that function, it calls getValue1 uses getValue2 as a callback, which in turn uses getTotal as a closure. This string of functions trickles the necessary information down to the final function that simply displays the total in the console. Nested functions play a big role when doing more complicated work where you need to make a comparison between two objects where you need to first pull down the two objects based on a unique id that is sent to the method.

While both Objective-C and JavaScript use closures and functions as callbacks, they are very different in how they do it. Thanks to first-call functions, JavaScript is able to easily pass a function around from function to function as a variable and execute it at any time. Objective-C, on the other hand, can pass a block to a selector and use that as a callback but is unable to pass a block to a block as a variable.

Asynchronous Programming

As of iOS4, blocks were released into the iPhone world opening up a much cleaner and more efficient way of asynchronously programming. Previously, you needed to use both NSThread and NSOperationQueue in order to queue up and run methods in a background thread:

So making an asynchronous call in a queue would require allocating memory to three different objects to be accomplished pre-iOS4. With the introduction of Grand Central Dispatch (GCD) alongside of blocks, Apple brought a better way to manage background threads while queueing up operations:

Simply put, it is much cleaner code and requires very few explicit memory allocations. The use of blocks in Objective-C has added to the codes readability and efficiency. It is clear that blocks primarily for closures. Being an object oriented language, there are limits to what functionality Objective-C can implement from a functional language standpoint. That being said,
it takes advantage of what it can and does a good job of making it work for the developer.