Drupal 8.0 Launch Day: What’s New?

First of all, Drupal 6.0 will no longer be supported on February 24th, 2016.

That’s coming up soon, folks!


If your site runs on Drupal, it’s time to prepare to migrate your site if you need to, or if you think you might need to! If you’re uncertain, today is a good day to speak with your site administrator(s), or web development partner, about a potential migration.

So what does Drupal 8.0 bring to the table?

It will take some time to truly assess the new additions. But what it clear right out of the gate is that 8.0 offers vastly improved admin themes that are (finally!) responsive. There’s also a number of features that should help make Drupal more application-development friendly. This is what remains to be seen. But, if true, could help make Drupal a more cost-effective solution for custom development.

It’s going to be interesting to open the box and see how these new changes work in practice. But there’s reason to believe that this new launch could help open the door for more would-be Drupal adopters.


Communication Breakdown: Web App

There’s a major problem in the world of app creation. You know what? I’d dare to go as far as to call it a minor crisis!

It’s a problem that stems from a simple but all too common miscommunication. It’s a case of semantics causing a complicated mess.

What is this catastrophe I’m referring to?

Folks are using the term ‘App’ when they really mean ‘Web App’ 


Theres are a number of differences between a ‘Native’ App and a Web App. And the cavalier use of the the word ‘app’ to mean one or both of these tools creates endless confusion. So let’s break it down.

First of all, if I’m honest, the most noteworthy of the difference between a Native App and a Web App is the amount of time and money it takes to see an ROI on a native app. This is because, in many cases, tons of money is wasted building an app when the focus would be better served on a well designed web app.

So what exactly is a ‘Web App’, anyways? Web-App-vs-Native-app

A Web App is basically just a device agnostic website; it’s a site that is built to fit all browsers, including mobile devices. It might even look and feel like a proper app. The functionalities can be near endless. But a web app is always run through an internet browser.

Don’t call a Web App an ‘App’, call it a Web App (or ‘Mobile’ Web App, if you prefer).

Native apps, on the other hand, are proper ‘Apps’

Apps are built exclusively for IOS, Android, etc. They are not run through an internet browser. They are extraordinary useful tools and can even be vital for some business models to survive and thrive.

Apps can be invaluable tools. We’ll get to that. But they have some major downsides. Here’s two big ones: they’re costly and reach a limited audience.

The truth is that not every organization needs an app. In fact, many organizations won’t even gain anything from a dedicated native app. On the other hand, every modern company or organization needs a web app. This is doubly true if any of your service offerings are web-based.

If you want the content housed in your website to reach as many people as possible, a mobile responsive website is your ticket

And doesn’t this definition fit the needs sought out by most organizations?

Even if you might find the need for a native app down the line, it almost never makes sense if your organization doesn’t first build a rock solid web app.

At the end of the day, you only need to ask yourself one question: ‘is your organization trying to accomplish anything that can’t be achieved in a web browser?’

If the answer is ‘no’. It’s probably wise to resist paying for an app.

If the answer is ‘yes’ then maybe it’s time to jump in.

And if you are unsure whether the answer might be yes, then here’s a list of the very real reasons to have a native app:

  • They’re fastercoomplcated-app-store
  • They’re available offline
  • Any manner of unique functionalities tied to a device (i.e. touch screen game(s), utilization of a smart phone’s camera or GPS)
  • Accessibility or ‘high-use’ service (is yours a service that over 10% of clients could realistically use on a daily or even weekly basis?)

Would any of these functionalities add considerable value to your brand? It’s a vital question to consider. And it’s made more complicated by the fact that your answer is likely to fall in a gray area somewhere.

Here’s a handy dandy infographic from Functionality that some additional context:


Key takeaway: Designing a great app is expensive

Finding a worthwhile ROI is extraordinarily tricky when it comes to launching an app. It’s why more and more organizations have learned to settle for extremely well designed Web App interfaces.

Ongoing Discovery in Process

Last week I wrote a post about the importance of discovery in process. More specifically, we considered why a business needs to formalize ongoing discovery if they’re to survive for the long haul. Today I’m going to focus less on the why and instead break down a few ways to put formal ongoing discovery into practice.

First of all, resist the urge to get lost in the details. Even if your core business offering isn’t web-based, our general access to web-driven data now allow us to hyper analyze the gritty details of our day to day like never before. This is thanks in part to increasingly robust customer relationship management tools. This intel can be immensely helpful, revelatory even. This tools allow us to streamline our processes and make our work lives ever-more efficient.

But here’s the rub!

The rigidity of these formal processes we develop can (and ultimately will) reach the point at which they close doors for new avenues of success.

agile-employeesIn web development, as with many industries, agility can be the victim of rigid process. Opportunities can be missed if processes like prospecting or even our approach towards servicing our existing clients are overly formalized. A balance must be struck between process and agility. It should go without saying that finding this balance is a difficult task; but you’ve already lost the battle if you don’t attempt to find that center of gravity between a streamlined process and the agility to tackle new, unforeseeable problems.

This is why a well designed process should leave room for the distinctions that make each project unique. It’s why a process for each new client or project should always begin with a Discovery Phase.

The Discovery Phase

This phase of work begins before a team even formally begins work on a project. But the common mistake is to confuse this phase with the prospecting phase; formal discovery comes after a project or client has been prospected. Discovery shouldn’t only be a matter of determining whether a project fits into your core services.

Avoiding this pitfall is where some digital agencies excel; their industry moves too fast to let evolving standards pile up before they’re noticed. And this brings us back to why slower moving industries might be able to learn quite a bit from their processes.

For projects to be developed in the web space, digital agencies approach each project as an opportunity to discover new solutions for even the most common challenges faced by our clients. It takes a sincere and formalized commitment to continued discovery to ensure that deliverables are built with the most up to date standards. Time needs to be formally allotted to research and discovery for every project, however cut and dry( or ‘standard’) the project might seem.

A Formal Process

Here’s where I can use Gulo’s process as a good example. The first stage of our Discovery Phase is our Strategic Brief. During this conference call with relevant stakeholders, we review project requirements in detail. This gives us a built in opportunity to begin thinking, at the highest possible level, about the web based solutions that might best service  a client’s mission and add value to their brand.


The real meat of our Discovery begins with a Needs Requirement. And this is pretty cut and dry, really. You have a problem. We might have any number of solutions. But to start thinking more analytically about all our options, we take some time to understand this problem from your perspective.

How does this problem affect your organization’s bottom line?

How will your stakeholders interact with this proposed solution?

These are the broad questions that get the discovery ball rolling even before a service contract is signed. In less slowly changing industries, it could be way too easy to assume that you know your clients industry, not noticing all the slow moving changes that have piled up.

Yet another Uber as a ‘Market Disrupter’ Analogy

Uber is way too popular an example for market disruption. But here’s a new way to consider how they affected industries:

How many behind-the-scenes transportation administrators failed take take time to discover evolving payment processing standards?


So what’s a good way to formally insert active discovery into your processes? Gulo has one method that you are free to steal.

Gulo’s Secret Sauce

Our ‘secret’ is simple, really. We allot time for research. For even the ‘smallest’ and most ‘cut and dry’ new projects are given at least two full hours of research-discovery.

This stage is where Gulo staff researches all available solutions, including new technologies. Part of this process can entail researching the solutions utilized by our client’s competitors. We also keep an eye out on the technologies utilized by other services that have not yet been applied to your unique niche. If such an option is viable, we’ll suggest this as an option.

Regardless of our specific findings, this research process forces us to stay agile. It puts new solutions to work whenever a project calls for an innovative approach.

time-management-schedulingResearch as a formal aspect of a discovery stage is a huge time suck, but its vital in our industry. Your industry likely requires less of a time allotment for you to stay ahead, but whatever time you may need, you ought to formalize it into your process.

Educational webinars, continuing education, time spent reading periodicals focused on your industry, none of these tasks should be optional activities. But these tasks also can’t fully account for an ongoing discovery process.

Put aside some time to formally research new support avenues with each new project. Each minute spent reevaluating your industry and taking in new, relevant info is insurance for your businesses future.

Fit ongoing discovery into your process. Or perish…