Skip to main content

Mobomo webinars-now on demand! | learn more.

We’re over the moon for NASA, who has just won a 2014 Webby Award!

Presented by the International Academy of Digital Arts and Sciences, the 20-years running Webbys are a highly respected and coveted Internet industry award. Touted as the “Oscars of the Internet”, Webbys are given for “Excellence on the Internet, including Websites, Interactive Advertising, Online Film & Video and Mobile content”. Past winners have included Al Gore, Meg Whitman, David Bowie, Prince, Thomas Friedman, and countless others—both individual and organizational.

watch-webby-awards-online

NASA is this year’s People’s Voice Award winner for Government: no small feat, as the Webbys notably bring in more than 1.5 million worldwide voters. What’s more? NASA beat out four other contestants with a whopping 59% of the votes! We are humbled to have worked alongside NASA and InfoZen to build this award-winning website.

Congratulations on your achievement, NASA! You’re out of this world.

Categories
Author

Mobomo was excited to accompany our client, Sister to Sister, just a few weeks ago at their first ever American College of Cardiology (ACC) Conference! Hosted at the Washington Convention Center, the ACC Conference consisted of a 3-day session devoted entirely to heart health and the latest developments in heart science. Thousands of cardiologists and those closely connected to heart health travelled from around the country (and further) to champion healthy hearts.

While there, Sister to Sister presented its heart risk assessment tool, Smart for the Heart, to conference attendees, and received a great response! Users loved the app’s simplicity, its vibrant colors, and the helpful recommendations it offered to aid them in their heart health journey. Our app’s credibility didn’t hurt either: cardiologists appreciated that it was based on the latest American College of Cardiology and American Heart Association science-based criteria!

Attendees also loved that Smart for the Heart is a women-focused heart health app, and we’re proud to be working with a notable leader in women’s heart health. We’re thrilled by the experts’ reception of Smart for the Heart, and looking forward to our continued partnership with Sister to Sister as they fulfill their mission of improving (women’s) heart health. To try the app and calculate your heart risk, search “Smart for the Heart” on iTunes or Google Play, or visit the web-based tool.

Categories
Author

crisp

The battle for consistent font smoothing is a universal struggle for web designers. Photoshop has its own proprietary way of displaying type, none of which accurately reflect browser rendering. Every browser renders type in its own way AND even operating systems have their own method of text rendering. Oy!

Consistency just doesn't seem to exist in the type rendering world. However, channeling my frustration into productivity, I did successfully implement a little trick in Google's Chrome & Safari (Mac OS) to counteract this dilemma.

Note: Before I dive into this technique, this is a solution for now, and while it works, its effectiveness is not definite.

Sub-Pixel Rendering

Sub-pixel rendering is:

Subpixel rendering is a way to increase the apparent resolution of a computer's liquid crystal display (LCD) or organic light-emitting diode (OLED) display by rendering pixels to take into account the screen type's physical properties. Source

What this means is the typeface, regardless of how it is being served (Typekit, Google, @font-face) is loaded and then computed at a sub pixel level. The smoothing happens in a space we can't see easily.

Because of this, some browsers (looking at you Chrome & Firefox) take beautiful, slender fonts and bloat them, making the edges appear jagged, losing the quality of beautiful, crisp shapes us designers crave in web type.

You Might Be Working With a Font That Doesn't Need Subpixel Rendering

This fantastic article from UsabilityPost does a good job illustrating why you should not remove sub-pixel rendering. This has been the de facto standard, working its way into many UI/UX practitioners toolbox. However, this article is more than a year old, and we are in a very different space then 2012.

High-PPI monitors and devices are changing how type is rendered and it wasn't until I got a retina MacBook Pro that my gears began to turn.

High-PPI Monitors Give us Leeway

Sub-pixel rendering is not an issue on retina devices. This is due to the high amount of pixels. The double pixels mean the canvas has twice the amount of space to render a font. I noticed right away that typography on a retina device is beautiful, the likes of which I set out to replicate on non-retina screens.

Here's My Solution:

I have been using this solution in a select few cases and it appears to have no detriment to a codebase. Note that this only works in Chrome on Mac OS X

First, I remove sub pixel antialiasing by using the antialiased property:

html {     -webkit-font-smoothing: antialiased; } 

Then, I take it one step further and target higher pixel density screens by using this media query fantastically crafted by Mike King, edited to only affect Chrome & Safari:

@media only screen and (-webkit-min-device-pixel-ratio: 1.25), only screen and ( min-device-pixel-ratio: 1.25), only screen and ( min-resolution: 200dpi), only screen and ( min-resolution: 1.25dppx) {     -webkit-font-smoothing: subpixel-antialiased; } 

The Rule

Custom fonts are becoming the web design standard and as more fonts are optimized for the web, less and less typefaces require sub-pixel antialiasing. This technique does not work with every typeface though and should be tested extensively. In addition, an extra sensibility is required when dealing with light type on a dark background.

If the typeface is optimized, you will have typography that shines on both retina and non-retina screens (only in Chrome on a Mac, but hey, that's better than nothing).

Check out my codepen for a demo

Keep the conversation going! We'd love to hear from you.

Categories
Tags
Author

Intridea jumped the pond last week to sponsor The Next Web; a conference filled with kitsch, Dutch food, and lots of tech!

As a TNW sponsor, we enjoyed every moment of our Amsterdam adventure; from the boutiquey lifestyles and infamous coffee shops and houses (note there is a difference) to the lovely folks that make Amsterdam what it is...

Here's a few snapshots from our trip.

TNW

Special thanks to TNW gurus, Anne and Simone, Headfirst Coffee Roasters, and all the awesome folks we met at TNW Europe!

Categories
Author


A few months ago, we quietly launched a dashboard helping remote distributed companies, like us, keep in touch. Working remote is great, but requires a level of strategy. With differing time zones, multiple projects, and varying schedules it can be difficult to keep everyone in the loop. Houston is our solution.

Since it's launch, we've utilized Houston to see who's on vacation, what cool projects everyone's working on, and revamp our company handbook via a Hipchat-powered Q&A knowledgebase. Best of all? We open sourced it, so you can use it too. Check out this two minute video and get the Houston dashboard up and running for your organization!


We can't wait to see how you use Houston. Fork it, add your own tools, and share it back. Houston is 100% built with Ruby on Rails, Bootstrap, and integrates with Google apps, Harvest, and Confluence.

Here's just a few ideas we've got coming up on our own Houston roadmap:

  • Who's online? Rollup of statuses across Hipchat, Google, and Github
  • Analyze Github commits for visualizing team skills
  • Where is everyone? Location and time zone indicator
  • Bookmarks: cool finds and helpful tips extracted from Hipchat logs

What do you want to add to Houston? Let us know!

Categories
Author

For Mobomo, the media coverage just keeps rolling in. This week, we are honored to be the feature of In The Capital’s latest tech profile!

The DC-based blog interviewed our very own founder, Barg Upender, to discuss our position at the forefront of the Mobile-Federal IT space, exactly what spawned Mobomo, and the various feats we’ve accomplished since our inception not long ago. Additionally, Barg gives some insight into our mobile development model, and what he predicts happening in Federal IT.

Head over to In The Capital for the full article!

Categories
Author

orange
Let’s face it, nobody likes a plain ol’ checkbox and sometimes (depending on what you're trying to accomplish), they can be tricky to style without dropping in a javascript library. Recently, while developing our new app Smashbook, I needed to replicate the native iOS style toggle switch. Attempting to replicate by using only HTML and CSS, here’s what I came up with...

We’ll start with the HTML.

          <div class=“setting”>         Off/On         <input type=“checkbox”>         <div class=“track”></div>         <div class=“toggle”></div>       </div>   

Pretty simple, right? Now for the CSS. This is the container for our toggle.

        .setting {       position: relative;       width: 200px;       padding: 12px;       border: 1px solid #9C9691;       border-radius: 4px;     }   

The only thing important here is the position: relative declaration. This allow us to absolutely position the elements contained inside it. The rest is completely arbitrary. Next, comes the toggle switch and track it will slide along.

        .track {       position: absolute;       right: 12px;       bottom: 6px;       width:50px;       height: 29px;       background: #9C9691;       border-radius: 15px;       box-shadow: inset 0 1px 3px #797470;     }   

And for the toggle:

        .toggle {       position: absolute;       top: 8px;       right: 34px;       width: 25px;       height: 25px;       border-radius: 50%;       border: 1px solid #8B8580;       background: #e1dcd7;     }   

Not too shabby! Now, just hide that pesky input and give it the same dimensions as the track, opacity: 0 and position it directly on top of the toggle and track. Note: the z-index of 2 ensures input is still clickable.

        input[type="checkbox"] {       position: absolute;       top: 8px;       right:12px;       width:50px;       height: 29px;       opacity: 0;       z-index: 2;     }   

Now, add the “clicked” state. Here the track will become green and the + will allow us to target the sibling directly succeeding the input.

        input[type="checkbox"]:checked + .track {       background: #a5cf42;     }   

The toggle will then move to the left side of the track. The ~ is the general sibling selector; this let’s us target any sibling element succeeding the input.

        input[type="checkbox"]:checked ~ .toggle {       right: 13px;     }   

Finally, add a transition to the track and toggle. This will give the toggle slide and the "track changing color" a more natural feel. Tada! There you have it.

        .track, .toggle {       -webkit-transition: all, 0.2s;       -moz-transition: all, 0.2s;       -ms-transition: all, 0.2s;       -o-transition: all, 0.2s;       transition: all, 0.2s;     }   

We implemented this for our upcoming product "Smashbook – Manage Your Tennis Data Like a Pro!” https://twitter.com/tennissmashbook

Also, here’s a link to Codepen.io, if you’d like to see a demo


Got any questions? Keep the conversation going! We'd love to hear from you.

Categories
Tags
Author

image

Back for more

In the last post we introduced a few new tools, covered a proposed RAD flow, used the DevRocket Photoshop plug-in, setup a GhostLab site and briefly addressed why designers should code.

In part two of this series, we'll cover:

  • Creating and using an app icon via the Ben Markowitz method
  • Adjusting our design to accommodate the default status bar
  • Adding the icon to your homescreen
  • Using Fastclick to make things feel quick-fast
  • Providing easy access to Framer views

Now, I know what you're thinking, "When are we gonna get to the good stuff?" Well, hang in there! I know these steps may seem like tedious prep work, but let's play make believe for a moment. Imagine you've just spent sixty-five hours crafting the most magnificent app imaginable. It's presentation time and you have to say this to the lead stakeholder...

 

“Ok, open Safari and go to this address…nope, sorry, make sure you add :8080…ok...oh, yeah, sorry, the browser's address bar pushes down the app, scroll up…don’t worry, it won’t be like that when we build it…”

 

Wait, did you hear that?

Splat.

That was the sound of your stakeholder’s confidence, in you and the app, hitting to the floor.

Now, imagine handing them the phone and saying:

 

“Open the app.”

 

Whoooosh! Delight

Thus, the “tedious work” could mean a world of difference in terms of how your work is received. Don’t worry, we’ll get to the meat and potatoes soon enough, there’s plenty to consume and digest here.

If you’re totally lost, check out part one in this series or mention me on The Twitter.

The Ben Markowitz: Less is More Method

Ben Markowitz is the man and after a lengthy conversation, with the infamous Brad Frost, developed an insanely simple method for adding icons to your homescreen with a single image.

Step 1: Make It

  • Pop open Photoshop.
  • Create a 512x512 document and make sure it's set to PNG 8-BIT with no transparency.
  • Don't worry about rounding the corners, the OS will take care of that.
  • Design till your heart's content.
  • Save your file as touch-icon.png

Step 2: Add Code

  • Add these two lines of code to the head of your HTML document. The first is for Android, the second is for iOS.

<link rel="shortcut icon" href="touch-icon.png">
<link rel="apple-touch-icon-precomposed" href="touch-icon.png">

  • For more information, read Ben's post.

Adjusting our design

While still in your HTML document, scroll down to the style tag and make the following changes to the body element:

 

  body {     background: #fff;     font: 28px/1em "Helvetica";     color: #FFF;     margin-top: -40px;     -webkit-tap-highlight-color: rgba(0,0,0,0);     -webkit-perspective: 1000px; } 

 

  • Remove the background image and set a margin-top: -40px to pull our design up a bit.
  • Doing so will pull your design up and hide the status bar that’s in the design. You could also crop your PSD but this is better IMO.

Adding the icon to your homescreen

This is probably the easiest part of this series, so feel free to skip ahead...

  • First, make sure your site is running in GhostLab and make note of the URL.
  • Grab your device and visit said URL in Safari. For example, I’d visit 10.0.1.2:8080.
  • Press the menu button (it looks like a page with an up arrow) and select “Add to Home Screen.”
  • Check the name, which should be the same as the title tag in your index.html file, and select “Add.”
  • If you’re like me, move the icon to a new screen where it can live by itself; it deserves a space of its own.
  • Open your app—Voilà full-screen app realness in effect.
  • Note: You must have GhostLab site running and be on the same network to view your app. The above does not install the app locally—that’s crazy talk.

Using Fastclick.js to make things feel quick-fast

Now that you’ve got your app running, you probably noticed a slight lag on press. This is due to the 300ms delay built into the Safari rendering engine. You can read all about it here. Thankfully though, there are some really smart people who wrote some fancy JS to help us with this: meet fastclick.

  • By default, Framer doesn’t create a folder for JS files, so create one in your project directory.
  • Open your editor and create a new JS file called utils.js—call it whatever you like, this is where we’ll house our apps JS.
  • Add utils.js to the bottom of your index.html file.

<script src=“javascript/utils.js">

  • Download fastclick.
  • Grab the fastclick.js file and copy it over to your newly created JS folder within your project.
  • Add it to the bottom of your index.html file.

<script src="javascript/fastclick.js">

  • Open utils.js and call up fastclick when the body loads.

 

  window.addEventListener('load', function() {     FastClick.attach(document.body); }, false); 

 

  • If you’re using jQuery, you’d use:

 

  $(function() {      FastClick.attach(document.body); });  

 

  • More info on using fastclick can be found here.

Providing easy access to Framer views

Phew, man that’s a lot of stuff to get up and running. We’re in the home stretch though, so stay with me, and we can finally start writing some Framer code. To start, we’re going to make accessing our Views at least 4x’s easier. According to the documentation:

 

“Framer added an object called PSD that has references to all your views by name. So if your layer group is called iPhone, you can access it's views with PSD.iPhone or PSD["iPhone”]."

 

The code would look something like this:

 

  PSD[“iPhone”].on("click", function() {      PSD[“iPhone”].animate({          properties: {scale: 2.0}      }) }) 

 

Thanks to Cemre Güngör and his awesome Framer Tips article, we can streamline this with a simple For loop. Thus rather than typing PSD.layerGroupName, if we add this code to our utils.js file, we can simply type layerGroupName...

 

  for (var layerGroupName in PSD) {     window[layerGroupName] = PSD[layerGroupName];     window[layerGroupName].originalFrame = PSD[layerGroupName].frame;     console.log(layerGroupName) } 

 

The above code says:

  • For each layer group in our PSD
  • Set the layerGroupName
  • Store it’s originalFrame data or hold onto the layer groups x, y, opacity et al for later use.
  • Spit out the layer group name via the JS console—this can be removed. Although, I find it to be a helpful reference when writing the animation code.

Before:

  PSD[“iPhone”].animate… 

After:

  iPhone.animate… 

 

Our utils.js file should now look something like this:

 

  // Quick-fast prototype interactions window.addEventListener('load', function() {     FastClick.attach(document.body); }, false);   // EZ access to views  for (var layerGroupName in PSD) {     window[layerGroupName] = PSD[layerGroupName];     window[layerGroupName].originalFrame = PSD[layerGroupName].frame;     console.log(layerGroupName) } 

 

Wrapping things up, for the time being

Wow man, we’ve covered a LOT. Don't know about you, but I'm pooped! For sanity's sake, let's take a moment to digest and reflect on our progress. To date, we’ve:

  • Introduced a few new tools
  • Covered a proposed RAD flow
  • Used the DevRocket Photoshop plug-in
  • Setup a GhostLab site
  • Briefly addressed why designers should code
  • Created app icons using the Ben Markowitz method
  • Used those icons and adjusted the screen to accommodate screen size
  • Made the app full screen by adding it to the home screen
  • Used Fastclick to make things feel quick-fast
  • Provided easy access to Framer views

That’s a sizable list and will only continue to grow as we move down the line. Make note, as this is valuable information when scoping your next RAD project. Coming up, we’ll review the app design, begin animating views, create the tab bar and iterate through its items to access different screens.

A quick note

I previously mentioned explaining the default Framer code in the last post—that’s changed. Instead, let's focus on the code we’ll write and keep things a little more consumable and tasty. Check out the overview video if you’re really curious.

Check out the entire Get RAD series below!

  • Get RAD, Part I: DevRocket + Prototyping
  • Get RAD, Part III: Animations + Framer
Categories
Author

heart
Since OpenSSL's Heartbleed bug hit the news last Monday, the media has covered the obvious bases: from what it is and what it does to various guides for recovery. However, despite all this, there hasn't been much focus on diagnosing affected services. Therefore, as a good citizen of the devsphere, I dug around for some answers...

Enter Filippo Valdorez's Heartbleed test, a web frontend for a command-line tool that performs attacks and reports if a service is safe or vulnerable. Using it is as simple as inputting the server hostname and clicking the "Go!" button.

The only downside is it's lack of multi-server verification or batch processing capabilities. However thanks to Heartbleed test's underlying command-line and a bit of research, I discovered a fairly straightforward solution.

Installation

The instructions from Heartbleed tool's README assumes that the Go programming language is installed on your system. Here's how to install Go if you are running on OS X:

$ brew install go 

After this, you will need to set your GOPATH in order to use the go get command. See below:

$ export GOPATH="$HOME/src/go" 

Lastly, ensure that whatever directory you set as your GOPATH exists:

$ mkdir -p $GOPATH 

Now you are ready to follow out the instructions from Heartbleed tool's README:

$ go get github.com/FiloSottile/Heartbleed $ go install github.com/FiloSottile/Heartbleed 

Since the GOPATH you set is not in your system's PATH, you'll need to cd into it before running the Heartbleed app:

$ cd $GOPATH $ bin/Heartbleed This is a tool for detecting OpenSSL Heartbleed vulnerability (CVE-2014-0160).  Usage:  bin/Heartbleed [flags] server_name[:port]  The default port is 443 (HTTPS). If a URL is supplied in server_name, it will be parsed to extract the host, but not the protocol.  The following flags are recognized:   -service="https": Specify a service name to test (using STARTTLS if necessary).         Besides HTTPS, currently supported services are:         [ftp smtp pop3 imap] 

Diagnosis

Now, with the application installed and ready to run, how do we verify whether an obscure service is affected?

For example, say we admin an OpenVPN server and want to make sure its not affected. To do this (making sure to substitute your server's hostname in for the made up one I use here), execute:

$ bin/Heartbleed vpn1.company.com:1194 2014/04/10 23:33:40 ([]uint8) {  00000000  02 00 79 68 65 61 72 74  62 6c 65 65 64 2e 66 69  |..yheartbleed.fi|  00000010  6c 69 70 70 6f 2e 69 6f  59 45 4c 4c 4f 57 20 53  |lippo.ioYELLOW S|  00000020  55 42 4d 41 52 49 4e 45  d1 ca 95 f8 c8 67 87 d7  |UBMARINE.....g..|  00000030  81 d1 a9 24 58 8e 66 52  08 1b 25 69 de b3 2e 00  |...$X.fR..%i....|  00000040  05 00 05 01 00 00 00 00  00 0a 00 08 00 06 00 17  |................|  00000050  00 18 00 19 00 0b 00 02  01 00 00 0d 00 0a 00 08  |................|  00000060  04 01 04 03 02 01 02 03  ff 01 00 01 00 a3 8f 47  |...............G|  00000070  c0 6d 38 25 7a 24 8f 24  5e 01 fa a8 97 fe ee 2b  |.m8%z$.$^......+|  00000080  30 fe d5 48 38 4a b9 eb  61 5f c3 0d              |0..H8J..a_..| }  2014/04/10 23:33:40 vpn1.company.com - VULNERABLE 

As you can see from the output above, my imaginary company's OpenVPN server is susceptible. Furthermore, seeing the results of this bug make it all the more real. Let's spend some time discussing exactly what the above output means.

Note that there are four columns. The first column contains offsets starting from 0, and is for presentation purposes. The next two columns are the raw bytes that come back from the attack, in hexadecimal format. Lastly, the fourth column is the human readable representation of the second and third columns.

It's worth bringing up that the attack is said to overflow 64 kilobyte chunks of memory. The above output, however, shows only 140 bytes. This is because the author intentionally restricts the payload so as to not leak any sensitive data. Normally considered quite small, 64 kilobytes is a lot of content in this context, and puts the seriousness of this bug into perspective. With 1024 bytes being 1 kilobyte, and 64 kilobytes being returned, the contents could be anything. For this reason alone, the Heartbleed bug truly is the stuff of nightmares for users and administrators alike.

Fixing Your Affected Servers

If you discover one or more affected servers, fixing the problem can vary based on the affected server's function. The Electronic Frontier Foundation has a thorough recovery guide detailing how to update your OpenSSL installation, rekey your servers, and configure Perfect Forward Secrecy. Utilize this guide for fixing these server specific functions.

OpenSSL's Heartbleed bug has definitely thrown a wrench in Internet security. However, we can combat it and identifying affected servers is one way. Hopefully this post can help ease this painstaking but necessary task!
Got questions, suggestions, etc? Keep the conversation going!

Categories
Author

mobomo-designer-gets-published

We’re happy to announce the latest title snagged by our Lead Designer, Paula Cintioni: published author! Based out of Buenos Aires, Argentina, Paula joined Mobomo in 2012, and has been creating world-class designs for our continually impressed clients. But they aren’t the only ones impressed by her work: in December 2013, Paula was approached by one of RedUSERS’ editors to start writing for their new collection of Digital Design guides.

RedUSERS is the leader in technology design/diffusion in Spanish, and they publish expert-focused magazines, books, collectibles courses, CD-ROMs, websites, e-books, newsletters and events. Their publications are distributed in all Spanish-speaking countries, including the U.S. Additionally, RedUSERS.com brings together the largest community of technophiles in Latin America.

Paula’s first articles covered Photoshop guidance and tutorials, how to successfully prepare files for printing, and advice regarding effective client relations, work ethics, and copyrights for newly minted designers. What’s more, Paula’s articles will have a wide reach: they will be featured throughout 24 monthly deliveries to hundreds of subscribers worldwide.

mobomo-designer-published

We’re so happy for you, Paula! To subscribe to RedUSERS (and read Paula’s fantastic insights), click the link here (may require translation).

Categories
Author
Subscribe to