• Read more about Lessons from Building Mission-Critical Government Apps

The headlines were unanimous: The mobile app used for tallying results during the Iowa Democratic Caucus was an unmitigated failure. Not only did it delay the outcome of the vote count, it cast a shadow on the integrity of the voting process.

What went wrong? Could it be, as opined by Vox, that “using an app to tally election results wasn’t such a good idea”?

Or was this simply a case of great idea, poor execution?

In this piece, we’ll examine what went wrong with the Iowa Democratic Party’s app, what a good app would have looked like, and how government agencies, political bodies, and other high-pressure groups can avoid the same mistakes.

How Not to Develop and Deploy an App

The problem surfaced hours after the caucuses ended. The Iowa Democratic Party had not reported results, citing inconsistencies in the reporting data. Officials were quick to say the delay was not caused by a hack or intrusion.

Still, speculation surfaced about possible security problems with technology. On Twitter, stories raising concerns about the caucus app’s vulnerabilities resurfaced. One of the top concerns cited in those pieces centered on the plan for caucus volunteers to download the app directly to their phones, which made it difficult to ensure the safety of the devices.

As the hours ticked by, chaos ensued, with the campaigns of two candidates claiming victory as the field headed east for the New Hampshire Democratic Primary on February 11.

What went wrong? As it turns out, quite a lot:

• Caucus field staff claimed the app wasn’t working properly. Some could not download the app. Others couldn’t sign into it, and still others complained that the backup method, reporting by phone, wasn’t letting their calls through.
• Cybersecurity experts and academics said the app was not tested at statewide scale or vetted by the Department of Homeland Security’s cybersecurity agency.
• And even if the app was working, reports suggest, the roll out of the tool was so badly botched that those responsible for reporting via the app weren’t trained on how to use it.
• The app was not deployed through traditional app stores or even sideloaded using an enterprise certificate. Instead, it was distributed through mobile testing platforms, including Apple’s TestFlight and a similar platform that services both iOS and Android called TestFairy. App developers and large software makers typically use testing platforms for mobile apps that are still in beta (i.e., not quite finalized). Developers can use the testing platforms to distribute the beta version of the software without having to go through the rigorous App Store and Play Store review processes.
• The app was distributed using the TestFairy platform’s free tier and not its enterprise one. Developers didn’t even pay for the TestFairy plan that comes with single sign-on authentication, unlimited data retention, and end-to-end encryption. Instead, they used the version of TestFairy anyone can try for free. It deletes any app data after 30 days and limits the number of test users that can access the app to 200.

In short, it appears that the app was rushed into use long before the necessary testing, training, and due diligence had taken place.

Rules of the App Development Road

Hindsight being what it is, it’s easy for observers to shake their heads and say, “We would never do that.”

But, how can they make sure? The key is to know what is required to develop an app the right way:

1. A rigorous, formal authorization process
2. A formal risk model
3. A formal threat model for the application

For example, developers working on federal websites must go through the security authority within their respective agency. That person confirms the application has gone through the FedRAMP certification process for cloud-hosted environments. The process confirms whether apps meet a standard set of 350-450 controls.

Some would argue there ought to be a similar formal process in place when software designed for government or public use is developed by external vendors. Unfortunately, the added work involved in meeting such standards would also add considerable cost to every project.

Fortunately, many developers still use those federal standards to establish clear frameworks while designing and testing their project. Working from the outside in, these developers consider such questions as “What boundary protections does this software need?” and “How does this software interface with other systems?”

Ready to Launch

State primaries and caucuses call for an app that is both secure and able to withstand rigorous load testing (i.e., the process of putting demands on a system and measuring its response). The app may work beautifully during standard testing but collapse completely once thousands of people start to use it.

As an example, Mobomo’s own load-testing procedures proved invaluable during the NASA.gov webcast of the “Great American Eclipse” in 2017. The NASA site typically has 10,000 - 50,000 simultaneous viewers. But on the day of the eclipse, NASA streamed the all-day event, which generated five to six times the streaming traffic of that year’s Super Bowl.

The NASA site performed superbly even under these conditions in part because it was designed to meet the FedRAMP continuity operation planning controls. These controls ensure that if one aspect of the software goes down, backup systems bypass the problem and the software continues to function with minimal interruption to the user.

And that’s the whole point of developing an app for a high-volume, high-pressure task like reporting data from caucus sites or primary voting stations: Using the best technology, the best processes, and the highest levels of expertise to make an app that works so smoothly and accurately, one would never realize the level of complexity and rigor that goes into developing it.

Mobomo develops and deploys secure, high-performance apps and websites for a broad range of civilian federal entities. Want to learn more about our work? Give us a call or contact us today.

• Read more about Why Design Thinking is Key

“Design for the user.”

It seems like a common sense approach. After all, if your website or your custom app aren’t designed with the end user in mind, will it get used?

Common sense notwithstanding, there’s a large gulf between the idea of designing for the user and the actual implementation of it. Plans go astray, different stakeholders have different ideas about what the user would want, and of course, there are always practical considerations like timeline and budget to consider.

Fortunately, design thinking can help project teams establish clear markers that keep them on track toward a seamless, positive user experience.

What Is Design Thinking?

Design thinking goes beyond the surface-level “design for the user” philosophy. It involves a highly tangible, iterative process that allows teams to move past their own viewpoints and levels of understanding in order to gain deep insight into the user’s needs and identify new strategies and solutions that might not have been immediately evident.

In short, design thinking is a process that gives teams concrete steps to help them get out of their own heads and into the user’s, to ensure the team is meeting the user’s genuine needs.

How Does Design Thinking Work With UX?

Most models of design thinking involve five steps:

1. Empathize: Understand your user’s pain points and greatest wishes.
2. Define: Figure out what problem the user is experiencing.
3. Ideate: Let creativity run wild and break down assumptions or traditions.
4. Prototype: Build a model that you can test with real users.
5. Test: Learn what works, what doesn’t, and then adjust.

Let’s explore these in more detail, in the context of UX design:

Empathize

The most successful apps and websites are those that were designed with the user firmly in mind. The folks at Interaction Design Foundation agree, saying that UX tasks “can vary greatly from one organization to the next, but they always demand designers to be the users’ advocate and keep the users’ needs at the center of all design and development efforts.”

But to do that, it’s necessary to understand who the user is and what they want and need. It’s also important to recognize if more than one user persona is in the picture.

Here’s an example: Let’s say we want to create a video app for children ages 6 to 12, with kid-friendly content.

In this situation, there are two main users that we need to understand: the children, and their parents.

• The children want intuitive (intuitive for them, not us) navigation, an easy way to binge-watch content from specific creators, and a fun way to interact with the creators and other viewers.
• The parents? They’re concerned about online predators and inappropriate content and want to make sure they have a way to keep an eye on things without having to constantly watch over their child’s shoulder.

These are fairly basic descriptions of user needs – and to really get a good handle on what each end-user wants from the UX, there’s only one foolproof method: talk to them. There is simply no replacement for sitting down with users and getting a first-hand account of what they need, like, hate, fear, enjoy, and find frustrating.

Define

The main challenge in this step is to clearly articulate the problem that needs to be solved, or the need that must be met.

Ideally, near the end of the Define process, there should be a clear answer to the blanks in the statement, “The user needs to _____________ because ________________.”

From there should arise a problem statement for the team to drive towards, such as “Create an easy and accurate way for both users and parents to filter and find video content.”

To get to this point, it’s vital for teams to take the data they gathered during the Empathize stage and process it in an organized, systematic fashion, unpacking the findings and discussing what they mean. A good practice is to keep asking “why,” digging down past surface-level problems and into the deeper, emotion-driven issues. From there, the data can be used to map out a User Journey, breaking down precisely how the user might interact with the app or site and what they’re looking for.

Ideate

In the ideate stage of design thinking, assumptions and constraints are thrown out the window. This can be much harder than it sounds – as we become more experienced, we often fall into certain patterns or draw on our existing knowledge, making it difficult to look at things from a completely different perspective.

In the ideate stage, “stupid” questions are often the key to unlocking new avenues, because those types of questions tend to disrupt long-accepted, “obvious” practices that should have gone challenged long before.

In the context of UX, the Ideate stage is crucial – it is too easy for teams to fall back into best practices or standard ways of designing the user experience. By applying design thinking, a team opens itself up for those “eureka!” moments that are only possible when the mind is open to every possibility, and it’s those moments that lead to groundbreaking design.

Prototype

This is where the rubber meets the road. Once a team has come up with what they think is the best possible way to design the UX for an app or website, they need to test the feasibility of that idea. And they need to test it with real users.

The prototype step can have multiple stages, from initial sketches, to wireframes, to actual working prototypes, all the way to beta versions that are available for a limited number of public downloads. The team may even create multiple prototypes if they’re not certain which idea will fly with users.

Test

Once the prototype is created, the team must learn — from real users — what works, what doesn’t, and then focus on iteration. To make the most of the testing stage, it’s absolutely crucial for the team to have in place mechanisms to gather and assess feedback. The more detailed the feedback is, the better the chances of fine-tuning any little UX issues that could harm the success of the finished product.

During the testing phase, it’s important that the testers not be coached or steered toward a certain type of feedback. Ideally, the team should refrain from telling testers what the purpose of the site or app is, or how it works. If testers can figure it out easily and accurately without any guidance, the UX is definitely on the right track. On the other hand, if the testers are confused about what the app or site is for, or how to use it, then both the messaging and the UX need some work.

The principles of design thinking can be applied to a multitude of challenges, and these principles truly shine when they’re applied toward the UX design of a website or application. By following a proven process that involves, above all, listening to the user, teams can create a finished product that will be enthusiastically embraced, adopted, and used for years.

Contact us now and find out how Mobomo's approach to design can benefit you.

• Read more about NOAA Fisheries Wins Webby Award in the Science Category

NOAA Fisheries (www.fisheries.noaa.gov) has won the 2019 Webby Award in the Science category!

Started in the fall of 2016, the ambitious project focused on merging all disparate Fisheries web properties under a single architecture, is jointly-led by the Office of Communications’ Director Kate Naughten and Chief Information Officer Roy Varghese. With support from their teams, the new NOAA Fisheries website was designed and built from the ground up to better serve their mission as stewards of the nation’s ocean resources and their habitat.

With a new design and content management platform, NOAA Fisheries was created using UI/UX tools such as card sorts, surveys, and journey mapping. Utilizing the findings, NOAA Fisheries designed and built a website that caters to all of its disparate users, including fisherman, scientists, and students.

The analyses and designs paid off. Since the launch of the new website, the customer satisfaction score has increased by 10%, from 65% to 75%, with 96% of users stating that the information they were seeking was easily found. This combined with a mobile-first website has also helped increase site traffic by 29% year-over-year, including a 67% jump in traffic during Shark Week when compared to the previous iteration of the website.

Mobomo has been thrilled to be part of an award winning team at NOAA Fisheries and look forward to solving new challenges with new innovations.

• Read more about Mobomo: Masters of Development, According to Clutch.co

Technology, updates, and trends throw things at us quickly, particularly in the web design and development worlds. Knowing what to do or how to adapt can be hard when you’re looking to update or strengthen your company’s digital presence, but that’s where Mobomo steps in.

With our expertise in creating cutting-edge, functional, and successful experiences, we’re pros at what we do, and we’ve become one of the top mobile app development companies in D.C. thanks to our passion and knowledge. In a recently published listing of which developers in the area reign supreme, B2B research and reviews agency Clutch ranked us no. 3 in a field of 100.

This distinction not only speaks volumes about the general quality of our mobile and web UI/UX, design, and development services but also reveals how strong our market presence, prior industry experience, and client feedback are individually. Thanks to such a thorough analysis from Clutch, we know that we stand out from top to bottom.

Nearly 20 reviews vouch for us, with our customers providing feedback like this:

“I’ve had ups and downs with contractors over the course of 20 years, but it’s always been smooth with Mobomo. We’ve developed a trust and have open, transparent communication. They don’t try to skip over us to work with the client. When they say they’re going to get something done by a deadline, it’s done. We’ve been pleased with the work they’re doing, the product they’ve created, and the way they’re managing the project.”

The Manifest and Visual Objects, sister companies of Clutch, have also appraised our work and come to similarly positive conclusions about what our team can do for clients.

Business news website The Manifest ranked us highly in its collection of web developers, featuring us among the top 100 companies in the entire world, while portfolio curation platform Visual Objects praised our work as mobile app developers in showcasing examples of our industry experience.

We’re grateful for all of the support that we’ve received and how this recognition reflects so well on the progress, people, and projects here. As our CEO said, "Mobomo is excited to be recognized by both Clutch and our clients as leaders in the industry. Our team of experienced designers, engineers, and product owners all take pride in their work and are ready to continue pushing boundaries and blazing technological trails."

Interested in hearing more about our approach, speaking to a member of our team, or learning more about how Mobomo can (and will) set your web or app experience apart from the rest? Reach out to us here. Let’s see what we can achieve together!

• Read more about Ionic Mobile Framework Featured at ModevCon

Modev started in 2008 as a Meetup group and over the years they have led the industry by organized conferences,strategic initiatives and provided executive leadership coaching to ensure those we engage with operate at peak performance.We were thrilled to have the opportunity to speak at the fifth annual Modev Conference on December 10th. Adam presented on the Ionic HTML5 hybrid mobile framework, where he talked about the framework’s background, as well as provided a quick dive into Angular.js, the popular javascript framework it’s built on.  

Be sure to visit http://withinsight.github.io/modev-ionic/ to see the full presentation 

• Read more about How to Create Responsive Images

With so many devices and screen sizes, it can be difficult balancing act to make your site look great and perform well. Displaying low res images on a high res display can make a site look terrible. On the other hand, serving high res images to a low res device can needlessly create a sluggish experience. Responsive images can help.

NOTE: Responsive image techniques are best used for CONTENT images (<img src=””>). For background images, you can and should use CSS media queries to control how the image is displayed across various devices.

The goal of responsive images is to provide multiple image sources and any other details the browser may need when deciding on an image.

WARNING: Parts of the syntax are very weird and the results may seem weird due to the long list of factors at play. These factors include, but are not limited to:

• Viewport size

• Image size

• Image display size

• Screen Pixel Density

• Cache

• Browser

• *Bandwidth

• *Browser settings (User preferences)

*Not currently implemented

Introducing the source set attribute:

Srcset allows us to provide multiple image sources as well as the size of each image. It may seem odd to inform the browser of our image sizes, especially since the browser can easily determine this on its own. However, the reasoning behind this is to give the browser a leg up on the selection process; allowing the browser to intelligently decide, prior to downloading, which image to request.

Taking it one step further with the sizes attribute:

The sizes attribute allows us to inform the browser of the image size being displayed on a page. It includes syntax similar to CSS media queries for responsive layouts where the image display size is determined by the layout.

Again, it may seem odd to inform the browser of something it can easily calculate on its own or it may seem odd to include redundant code from CSS, but providing this info before the browser even has the CSS files will improve performance.

A bit more control with the picture element:

Lastly, the picture element provides more control, using media queries, to explicitly narrow down the browser’s selection of image choices. This is useful for implementing art direction or when image sizes change so dramatically they must be uniquely cropped for every layout.

Responsive images can be complex. However, when done properly, they can provide the very best experience for any situation.

For more details check out our codepen:

[codepen_embed height=300 theme_id=1 slug_hash='qdMQdb' user='Mobomo LLC' default_tab='result' animations='run']

• Read more about Why Drupal? A Look Into A Leading CMS (Part 1 of 3)

Regardless of industry, staff size, and budget, many of today’s organizations have one thing in common: they’re demanding the best content management systems (CMS) to build their websites on. With requirement lists that can range from 10 to 100 features, an already short list of “best CMS options” shrinks even further once “user-friendly”, “rapidly-deployable”, and “cost-effective” are added to the list.

There is one CMS, though, that not only meets the core criteria of ease-of-use, reasonable pricing, and flexibility, but a long list of other valuable features, too: Drupal.

With Drupal, both developers and non-developer admins can deploy a long list of robust functionalities right out-of-the-box. This powerful, open source CMS allows for easy content creation and editing, as well as seamless integration with numerous 3rd party platforms (including social media and e-commerce). Drupal is highly scalable, cloud-friendly, and highly intuitive. Did we mention it’s effectively-priced, too?

In our “Why Drupal?” 3-part series, we’ll highlight some features (many which you know you need, and others which you may not have even considered) that make Drupal a clear front-runner in the CMS market.

For a personalized synopsis of how your organization’s site can be built on or migrated to Drupal with amazing results, grab a free ticket to Drupal GovCon 2015 where you can speak with one of our site migration experts for free, or contact us through our website.

______

Drupal in Numbers (as of June 2014):

• Market Presence: 1.5M sites
• Global Adoption: 228 countries
• Capabilities: 22,000 modules
• Community: 80,000 members on Drupal.org
• Development: 20,000 developers

Open Source:

The benefits of open source are exhaustively detailed all over the Internet. Drupal itself has been open source since its initial release on January 15, 2000. With thousands of developers reviewing and contributing code for over 15 years, Drupal has become exceptionally mature. All of the features and functionality outlined in our “Why Drupal?” series can be implemented with open source code.

Startup Velocity:

Similar to Wordpress, deploying a Drupal site takes mere minutes, and the amount of out-of-the-box functionality is substantial. While there is a bit of a learning curve with Drupal, an experienced admin (non-developer) can have a small site deployed in a matter of days.

Information Architecture:

The ability to create new content types and add unlimited fields of varying types is a core Drupal feature. Imagine you are building a site that hosts events, and an “Event” content type is needed as part of the information architecture. With out-of-the-box Drupal, you can create the content type with just a few clicks--absolutely no programming required. Further, you can add additional fields such as event title, event date, event location, keynote speaker. Each field has a structured data type, which means they aren’t just open text fields. Through contrib modules, there are dozens of other field types such as mailing address, email address, drop-down list, and more. Worth repeating: no programming is required to create new content types, nor to create new fields and add them to a new content type.

Asset Management:

There are a number of asset management libraries for Drupal, ensuring that users have the flexibility to choose the one that best suits their needs. One newer and increasingly popular asset management module in particular is SCALD (https://www.drupal.org/project/scald). One of the most important differences between SCALD and other asset management tools is that assets are not just files. In fact, files are just one type of asset. Other asset types include YouTube videos, Flickr galleries, tweets, maps, iFrames--even HTML snippets. SCALD also provides a framework for creating new types of assets (called providers). For more information on SCALD, please visit: https://www.drupal.org/node/2101855 and https://www.drupal.org/node/1895554

Curious about the other functionalities Drupal has to offer? Stay tuned for Part 2 of our “Why Drupal?” series!

• Read more about Apple Watch: A Look Inside

At the time of this writing (pre-WWDC 2015), there are a number of limitations on what Apple Watch code can do. The primary limitation is that watch apps cannot exist by themselves. It is necessary for the watch app to be a part of a corresponding phone app. Apple has said they will not accept watch apps where the phone app does not do anything itself. Also, watch-only apps (such as watch faces) are not allowed for this same reason—although it’s rumored that this may change after WWDC 2015.

Another Apple Watch limitation is that Core Graphics animations are not supported, but animated GIFs are. Complex layouts (such as overlapping elements) are not allowed. However, elements can be positioned as if they overlap—provided only one element is visible at a time. Using actions such as taps and timers, the visibility of these "overlapping" elements can be changed. This can be implemented to provide a more dynamic interface. Another major limitation (also whispered to change after WWDC 2015) is that watch apps cannot access any of the hardware on the watch including the motion sensor and heart sensor.

Most watch app processing (controller logic) is done on the phone instead of the watch, and some delays are inherent in the Bluetooth communication that transpires between the watch and the phone as the view (on the watch) talks back to the controller (on the phone). This view/controller split is not obvious in the code, but the watch/phone split is obvious in the code, as the watch cannot access anything from the phone, even though the controller logic is running on the phone side—except via a specific watch-to-phone request.

One notable feature is the watch app’s ability to explicitly call the phone app with a dictionary and obtain a dictionary response. This functionality allows the developer to then set up a number of client-server style requests, where the watch is the client, and the phone is the server. For example, the watch can request information from—or record information to—the phone. The phone (which has storage and may have Internet connectivity) can then fulfill the request and provide data in response to the watch. This can drive the phone app's UI to provide near-real-time synchronization of the watch app display, as well as the phone app display.

Custom notifications (both local notifications and push notifications) are supported on the watch. These custom notifications can have a somewhat customized layout as well as having the ability to define a set of custom actions. After performing one of these actions, the watch app is started. Apple mentions not to use notifications as a way to just launch the watch app from the phone app. Apple maintains that the notifications should provide useful information.

One developer test limitation relates to custom watch notifications (for local notifications).  Since watch notifications are only displayed if the phone is asleep, there is no direct way to test custom watch notifications.  Because of this, XCode does provide a mechanism to test push notifications in the simulator (using a JSON file), but there is no similar mechanism to test local notifications. Still, one can certainly test local notifications with the physical device.

• Read more about The Internet: A Brief History

And, in keeping with his Developer DNA, the history lives on GitHub: to navigate, please use your left and right arrow keys.

Bonus: watch Ryan make a real time web app in his brief intro of AngularJS!

• Read more about Federal Mobile Computing Summit 2014: Government in the Future

We were particularly proud to see one of our favorite clients, Peter Dewar, Chief Technology Officer at the District of Columbia Retirement Board (DCRB), participate in a thought-provoking panel on Wearables and the Internet of Things. The session's description as a “visionary panel” proved to be true, as all of the participants outlined the groundbreaking mobile capabilities they foresaw as feasible within the next five years.

Mr. Dewar described his vision for implementing Google Glass in the office, at conferences—even for pension fund participants, staff, and Board members. Taking the idea of “smart rooms” even further, he also described a futuristic conference room, which would be able to set up a meeting’s required media (think dial-ins, projectors, etc.) upon the meeting organizer’s entrance or (biometric) authentication.

We from Mobomo were on the edge of our seats thinking about the possibilities, and excited about building them—especially for our government clients. Congrats to Peter Dewar for a great panel session, and thanks to Tom Suder for hosting yet another fantastic summit. We’re looking forward to next year’s—and to the future of mobile (in the government!).