• Read more about NASA Uses "Headless" Drupal To Reach New Website Heights

In April 2015, NASA unveiled a brand new look and user experience for NASA.gov. This release revealed a site modernized to 1) work across all devices and screen sizes (responsive web design), 2) eliminate visual clutter, and 3) highlight the continuous flow of news updates, images, and videos.

With its latest site version, NASA—already an established leader in the digital space—has reached even higher heights by being one of the first federal sites to use a “headless” Drupal approach. Though this model was used when the site was initially migrated to Drupal in 2013, this most recent deployment rounded out the endeavor by using the Services module to provide a REST interface, and ember.js for the client-side, front-end framework.

Implementing a “headless” Drupal approach prepares NASA for the future of content management systems (CMS) by:

1. Leveraging the strength and flexibility of Drupal’s back-end to easily architect content models and ingest content from other sources. As examples:

• Our team created the concept of an “ubernode”, a content type which homogenizes fields across historically varied content types (e.g., features, images, press releases, etc.). Implementing an “ubernode” enables easy integration of content in web services feeds, allowing developers to seamlessly pull multiple content types into a single, “latest news” feed. This approach also provides a foundation for the agency to truly embrace the “Create Once, Publish Everywhere” philosophy of content development and syndication to multiple channels, including mobile applications, GovDelivery, iTunes, and other third party applications.

• Additionally, the team harnessed Drupal’s power to integrate with other content stores and applications, successfully ingesting content from blogs.nasa.gov, svs.gsfc.nasa.gov, earthobservatory.nasa.gov, www.spc.noaa.gov, etc., and aggregating the sourced content for publication.

2. Optimizing the front-end by building with a client-side, front-end framework, as opposed to a theme. For this task, our team chose ember.js, distinguished by both its maturity as a framework and its emphasis of convention over configuration. Ember embraces model-view-controller (MVC), and also excels at performance by batching updates to the document object model (DOM) and bindings.

In another stride toward maximizing “Headless” Drupal’s massive potential, we configured the site so that JSON feed records are published to an Amazon S3 bucket as an origin for a content delivery network (CDN), ultimately allowing for a high-security, high-performance, and highly available site.

Below is an example of how the technology stack which we implemented works:

Using ember.js, the NASA.gov home page requests a list of nodes of the latest content to display. Drupal provides this list as a JSON feed of nodes:

Ember then retrieves specific content for each node. Again, Drupal provides this content as a JSON response stored on Amazon S3:

Finally, Ember distributes these results into the individual items for the home page:

The result? A NASA.gov architected for the future. It is worth noting that upgrading to Drupal 8 can be done without reconfiguring the ember front-end. Further, migrating to another front-end framework (such as Angular or Backbone) does not require modification of the Drupal CMS.

• Read more about Mobomo Announces Management Changes

We are excited to announce expansion and growth of Mobomo's executive team:

Ken Fang, formerly CEO, will now serve as President of the company. Since joining in 2010, Ken has led Mobomo from a small startup to a company with over $5M in annual revenue, a more than tripled staff, consecutively high rankings by Inc. 5000, over 120 product launches, and an increasingly glowing client roster. In Ken's new role, he will be focused on high-level company strategy, corporate partnerships, and sales.

Brian Lacey will be assuming Ken's responsibilities as CEO. Brian joined Mobomo in 2011 as a Project Manager, and because of his passion for UX design, was quickly promoted to Creative Director. Within a short period of time, Brian was soon appointed COO, and under his tenure, Mobomo successfully built out well-defined design, development, and quality assurance capabilities. He also spearheaded the founding of the Buenos Aires office and helped acquire Exceptual Technologies, among other operational expansions.

Jesse Vizcaino will be assuming Brian's responsibilities as COO. In 2012, Jesse launched his Mobomo career as a Project Manager and quickly rose to Director. In his various roles, he has been instrumental in guiding Mobomo’s strategic direction, streamlining operations, and signing flagship customers such as the District of Columbia Retirement Board and the National Library of Medicine.

Please join us in congratulating Ken, Brian, and Jesse: we’re excited to see the great things they’ll accomplish in their new roles, and wish them all the best.

• Read more about NASA Launches Orion On First Step to Mars

At 7:05am EST today, the world watched as NASA released its unmanned spacecraft, Orion, into the ether. With Captain Kirk (in doll form) at the helm, the massive capsule soared from Cape Canaveral with countless hopes attached. This new spaceship was built with one goal in mind: deep space exploration.

Orion’s 4.5 hour flight test was a critical step toward eventual near-Earth asteroid excursions, trips around the moon, and--most significantly--manned missions to Mars. That's right: with the success of Orion's launch would come “the beginning of the Mars era,” as NASA Administrator, Charles Bolden, remarked before blastoff.

And succeed it did! Completing two orbits and going farther than all rockets designed to carry astronauts have in the past four decades, Orion passed with flying colors, and landed in the Pacific Ocean at 11:29 this morning. Our biggest congratulations to NASA on an incredibly successful flight test! Mobomo is proud to be part of the team supporting NASA.gov.

• Read more about The DNA of Web and Mobile Products

Last week we sponsored MoDevUX, a mobile conference in Washington, D.C. led by vanguards in the mobile development and design industry. In addition to learning about emerging trends from the diverse crowd of presenters and attendees we also shared a bit of our own "secret sauce".

Anthony Nystrom, our Director of Mobile and Emerging Technologies, shared the stage with Jurgen Altziebler, our Managing Director of UX to tackle the topic of "Development and Design: When the Two Must Act As One".

Through cultivating a culture of quality in both design and development we've gained insights on the formula for success among teams of developers and designers. MoDevUX was an opportunity for us to share those insights with the greater mobile design and development communities.

Designoper, Developer or Designer, the point is that recognizing each other's skills while sharpening your select personal skills is what a team is built upon. Certainly there are stars, however stars don't scale but teams most certainly do! And like any business that is looking to grow, it must rely upon teams that are less interested in their personal prowess and more interested in their unified presence.

Great Products: Under the Hood

If you're building a product you already know that it's important to know your industry, understand your users, define a clear vision and path of execution, and to be bold in your approach. But what role does your team of developers and designers play in the overall viability of your product?

We believe the DNA of any mobile or web product is embedded in the team(s) that are executing on the vision. Ultimately, every product is really just someone's good idea made accessible by teams of programmers and designers. Therefore, the most important factor in the success of your product is the team of experts building it. At Intridea we've been honing the process of creating these teams for years, and with great success! We do it in large part by making sure our teams of developers and designers are working together, not autonomously.

Building a Design & Development Team

Often, design teams work in isolation from development teams and in many cases design is outsourced to other agencies while development is done in-house or vice versa. But there's no doubt about it, a great product experience is the direct result of a good working relationship between the teams building the functionality (the developers) and the teams creating the aesthetic experience on top of that core functionality (the designers).

Of course, simply knowing that designers and developers should work hand-in-hand doesn't mean it's going to be easy. After all, designers and developers are different breeds and both groups work in distinctly mysterious ways. The trick to building solidarity in a product team is to hire the right kind of people in the first place.

While you might be inclined to seek out "rockstars" for your team, keep in mind that superheroes get bored easily, they're hard to find, and they don't scale. We have found that it's more advantageous to focus on hiring specialists who meet these requirements:

• Have the skills (and attention span) to see a project all the way through (even that last 10%)
• Are great at a couple of core things but are eager to learn beyond the bounds of their specialty (i.e., beware of "backend" developers who refuse to do "frontend" work)
• Leave evangelism to theocrats: you want people who aren't afraid to use different technologies (whether they're cutting-edge technologies or older technologies that just happen to be the right tool for the job). Find people who love the challenge of creating something incredible regardless of the tools and processes used to get there.
• Value form as much as function. It's important to see the inherent value in both a well-architected application and an easy-to-use, beautiful user interface.

In a symbiotic designer/developer relationship, both sides will, at some point, be faced with setting aside ingrained methodologies in order to collaborate effectively. What's actually happening in those cases is something like this: designers are learning something new about practice patterns in development, and developers are learning something new about user flow and experience from designers. When designers and developers work together in such a way, both teams gain something and will be more agile, productive and innovative on future projects.

Setting the Team Up For Success

Managing a product team is generally no easy task. Ask the design team to work in collusion with the programmers and it's sure to get even more challenging. Jurgen shared his strategy for creating a "balanced" team and setting them up for success on any project.

• Team Building: This is an important first step. Assign an internal project (maybe a redesign of your company's website) to a developer and a designer. In this situation they will have to manage the project together, understand how the other one works, communicate in-depth about scope, features, and blockers on the project, and deliver a finished product.
• Field Testing: Once you've ensured that the designer and developer can work together, pair them on a mid-sized client project. This adds a bit of necessary pressure because client deadlines are often more strenuous than internal deadlines. Additionally, a client project will introduce more variables for both sides. They'll have to think about things like client expectations, changes in scope and direction for both UI and architecture, and more.
• Heavy Lifting: Now your designer and developer are battle-hardened and ready to lead the troops. Appoint this dev/design duo as the lead for larger projects that have multiple designers and developers. Their experience will aid them in helping other designers and developers work together, maximizing the results of the process.

But I Just Want A Good Product That Will Be Profitable

You have an idea. You need a product built. It sounds easy enough. Do you really need to spend all this time thoughtfully building the team behind the product?

In short, yes. Great products fail all the time; and not because there wasn't a good idea behind it. They fail because the teams building the products couldn't meet at that magic place - the precipice of awesome. (No, really - amazing things happen when designers and developers work together closely!)

Keep in mind, there isn't a lot of room for failure, especially in the mobile app market where users are educated and discerning and the competition is cutthroat. It's not even that users are "demanding" sexy interfaces and well-built applications - we're beyond that. Today, users just expect it. And if your product doesn't meet expectations your users won't even complain about it - they'll simply move on to another application that does it better.

These are problems that you rarely see when you have a team of designers and developers working closely on a product because simple issues like awkward user flow, unintended behavior within the interface, and architecture miscalculations are caught more frequently and earlier on in the process.

The Secret is in the Sauce

So there you have it - a sampling of our "secret sauce". TLDR: Hire smart people who value quality and aren't afraid to cross the "party lines".

Be sure to go through the complete slide deck from our presentation at MoDevUX, and check out our portfolio where you'll get to see some great examples of recent products and solutions built by our teams of designers and developers! Additionally, the full set of photos from the event is available on our Flickr page.

Do you have insights on helping designers and developers work together on projects? We'd love to hear it. Did you see our presentation at MoDevUX? We want to know what you thought. Leave your feedback below or reach out to us on Twitter.

• Read more about Grease for Squeaky Products - Tips from QA Land

As a QA Manager who often oversees more than a dozen projects at a time across both client/services and internal/product development I get an inside look at what helps projects succeed. Today I’m pulling my head out of the depths of QA Land to give you an important tip that’s been rattling around my brain cage for the last couple of weeks:

The squeaky wheel gets the grease

In other words, speak up. And keep speaking up until something is fixed.

Now I know that proverbs are silly to use since many of them are so contradictory: “good things come to those who wait”, right? Listen up folks — in the world of software development, good things do not come to those who wait. In fact, waiting around does absolutely nothing except tank your chances for successful delivery and implementation.

People have all different kinds of reasons for not speaking up: they’re too busy, they don’t want someone to think they’re complaining, they don’t want to feel like they’re a burden to the person who will have to make the fix, they don’t want to appear to be negative, etc.

Whether you’re a developer, a designer, or just someone who happens to be clicking around in an application it’s vital to speak up when you encounter things you aren’t expecting, or bugs, or undesired behavior from the application. The people that are working with the project are usually so deeply involved that it’s easy to miss surface-level mistakes that might seem so apparent to someone else. And if you don’t raise your voice about it, it might not ever get “greased”.

Here are some basic tips for “squeaking up” and getting heard:

Do:

• Contact someone on the project and politely let them know what sort of ugly bug you’ve uncovered.
• Be as specific as possible about the problem – give information about what browser (and version) you were using at the time, which OS, etc.
• Take a screenshot if possible and annotate it, conveying the issue as clearly as possible.
• Be proactive and create a ticket, including all of this helpful info about the bug in the ticket notes. This saves QA a step and ensures it gets (and stays) on their radar.
• If the issue isn’t resolved, be sure to follow up with someone about it (politely, of course).
• Explain the reasons you don’t agree with a certain type of functionality, citing helpful examples.

Don’t:

• Yell about the problem from across the room, which will inevitably make the QA and dev team feel like you’re making a long-ranged attack.
• Contact someone higher up in the chain than you need to – just report the issue to the person(s) that is working with the code daily and can help take care of the problem. Going above their head is an adversarial move.
• Get angry if people disagree with your insights about a type of functionality – maybe you don’t see the reason for it, but the dev team insists, even after open discussions about it, that that particular functionality has to remain as-is.

In short, your product won’t be a great product if it’s chock full of holes, nasty bugs, odd functionality, and so forth. It’s everyone’s job to report the wonky things they come across, even if you don’t want to “bother” people. You can be “squeaky” without be “squawky.”