Olive Technology, Inc
5350 Academy Blvd, Suite 202,
Colorado Springs, CO 80918
Phone: + 1-719-785-5786
Olive Technology Limited
308 Lumbini Rockdale, Somajiguda
Hyderabad 500082
Phone: +91-40-2339-9312
Almost thirty years ago, I became an early adopter of what was then called cell-phone services. When my phone arrived, I had to go shopping for a separate back-pack to carry my new phone. It was the size of a large brick; two bricks actually one for the phone and the other for the battery. I had moved ahead of my peers, because I was now digitally connected, even if I rarely took it out of my car.
A few years later, I moved down to a smaller brick, the Blackberry, which was more convenient, but still just a mobile phone. Today, I am rarely a few feet from my iPhone. However, it is no longer “just a phone”. In fact, my actual telephone call usage is less than 20% of the time I spend using this device. There are several devices that I rarely use anymore, like my desktop computer to check on my e-mail, or search the web. I only use my land line telephone as a second line while I am on my mobile phone, or to respond to persistent individuals who are not satisfied with just leaving a voice mail.
These individuals are also the ones that send me text messages, because they feel the need to reach me immediately. I don’t know why, I am not a doctor, whose patients require immediate attention. My daughter also uses it to inform me that dinner is ready, so she does not have to yell at me from downstairs.
Mobile devices have moved past the exchange of information, to providing critical medical services. Olive is currently developing apps that allow patients to upload blood test results and enable doctors to monitor patient’s progress remotely. The bi-directional communication eliminates the need for weekly visits. Doctors can also review monthly charts and prescribe medication changes if necessary. With connectivity to other apps, prescriptions can be delivered to the patient. In the not too distant future, your device can instruct an insulin pump to increase or reduce insulin. Olive has other clients who provide mobile devices to inspectors working in the agriculture industry to manage food safety.
As the proliferation of these devices grows, applications for their uses are growing exponentially. Who would have considered that charity and other non-profits would use them as bidirectional fund raising devices? Yet after every major disaster, the ability to contribute from your mobile device is an option. Political campaigns now use a mobile strategy to collect donation and measure public opinion. There are those who suggest that mobile phone communications were responsible for bringing down governments in the Middle East.
Two mistakes that many organizations make, are first assuming that an internet or web strategy is the same as a mobile strategy. They are not. The experience and impact in a mobile strategy is broader and faster moving. The second mistake is not getting expert assistance. Whether you need is to distribute information and product, solicit sales or donations, or communicate with service providers in the field, each task requires specific design, architecture and user interface. Do it yourself applications, rarely address the full strategy.
At Olive, Mobile Strategy is one of our strengths. Give us a call, and we’ll help you develop a plan and implement it before your competition does. Also, we can do it for a lot less time, effort and money than you thought possible.
For most companies involved in the development of hardware and software solutions, delivery of the product marks success. “High fives” are exchanged and product managers say “sabash!” to those who worked diligently in making the screens do the bidding of the end user. In my opinion however, this is not the point to mark success. Success is defined by the user’s confidence that the investment in hardware and software will:
I bring this point of view to my role as Director of Marketing and Client Services. I recognize that I can do nothing without the extraordinary and experience skills of my technologically oriented colleagues, and it is understandable that they are pleased when a product is turned over to the client. I hold this perspective because my role starts at the first client meeting, and ends long after the client signs off on product acceptance.
A case that illustrates my point is the crisis regarding the initial performance of the Healthcare.gov website created in response to the Affordable Care Act (Obamacare) in the United States. For most technology experts, including those who designed this website, their stated objective is to make the website work, and that will be success. I disagree. Success is when 47 million users who could not previously get health care log into the website and easily purchase medical insurance available under the current law. Technology for the sake of technology alone is meaningless. It must have a purpose.
When I meet with a prospective client, I rarely ask them “what” they want to do. I ask them “why” they want to do what they want to do. I listen for answers like, “not having to enter the same data in three different systems, or having to log into multiple systems where the information is not consistent; or being able to serve expanding demands without having to increase costs or hire additional staff.” These are the “whys”, around which that senior management makes their decisions. It rarely involves technology. In my last appointment, we surveyed the actual end users. These are the people who know what will make their work easier and more efficient. In this case, the organization was able to justify the cost of a $90,000 investment, in one year from labor costs alone. Again, no one spoke about the technology. My role is to help the customer define objectives and expectations.
Throughout the development process I am in constant discussion with the developers and the customer. This task can be frustrating, as I help to improve communication. I reconcile the developers’ attempts to satisfy a customer with the extra changes the customer requests to customize the system the way they want. A customer’s lack of knowledge can sometimes become a hurdle. The organization may not have the knowledge of how a system is developed and how seemingly small changes can create delays and increase in costs.
After the system is turned over, my task starts to ramp up as I work with the client. My goal is not to obtain a signature on a legal document, but to truly deal with the issue of customer satisfaction. Did the product meet their perceived promises? I work with training the end users and again listen for phrases such as, “this would work better if . . .” or “if it could just make coffee, too!”
Referring back to the Obamacare website, I believe that the development task was assigned to a group of people who saw the objective as collecting information, instead of providing users with options. Governments and bureaucrats can and like to do that. In contrast, Olive is concerned with providing options to our customers.
Investing in technology that is already obsolete is a bad business strategy. In the second post of this series, we’ll explore an obsolete way of developing web apps as well as a transitional approach that has become popular. It’s important for you to understand these two paradigms of web application development to truly understand the benefits the next generation of technologies that are emerging.
We can break up the history of web apps into three broad phases:
These are generalization. They have to be, the Internet is old and its history complex. Arguably, you can find conceptual traces of the Internet back in Murray Leinster’s 1946 short story, “A Logic Named Joe.” Early experiments with internet’s primordial form, ARPANET, go back to 1969. The World Wide Web (“The Web”) was proposed in 1989. Regardless, the nuanced specifics of the web’s history aren’t important for our immediate goal. You need to learn just enough about the last fifteen years of web technology so that you can make the right decision for your next project.
By early 2001, the 12 year old Web had already given birth to the idea of Software as a Service (the broad term for web applications). Sure, the underlying concepts go back to earlier days, but the Internet presented a new opportunity for Application Service Providers to distribute their services. Let’s pick this as an arbitrary line in the sand as to when First Generation (Gen-1) Web Apps came onto the scene. The exact year is irrelevant.
Gen-1 web apps were born during a time when web standard technologies like HTML and Javascript were relatively young. You had a variety of web browsers made by fierce competitors. The 1990s had given birth to Mosaic (later Netscape), Internet Explorer (IE) and Opera. By the early 2000s, Internet Explorer dominated. Later, you would have Firefox and Google Chrome, but for the moment it was Microsoft’s time in the spotlight.
Gen-1 apps can be characterized by the use of Server Side Rendering that results in browser refreshes as the user’s interaction with the app causes round trip requests to the server.
For example:
Your browser is just collecting information, passing it to the server and asking the web server what to display next.
With Gen-1 web apps, the server does all of the heavy lifting and the browser acts as a fairly “dumb” terminal that’s primarily responsible for gathering information and displaying results from the server.
HTML is the way information is encoded so the browser knows how to display that information. This page that you’re reading is defined using HTML, which has been translated by your browser and then rendered onto your screen. HTML is not a programming language. It’s a markup language that is primarily concerned with the structure of information. It defines things like:
Javascript is the programming language of browsers. It has been around since 1995, but its evolution was fairly slow until the last ten years.
Gen-1 apps use Javascript for their browser side programming language, but the implementation is largely limited to validating input (e.g., making sure you put an email address in the email box, etc.). Or, it is used for trivial interface tasks like animating your menus or making sections of the page disappear and reappear depending on whether or not a button was pressed.
Gen-1 web apps are pretty obvious when you’re using them. If you enter some information, press a button, then see your browser refresh the entire screen with some results… you’re working with a Gen-1 application.
Gen-1 Web Apps are obsolete, but they’re far from irrelevant. You likely encounter them on a regular basis, and amazingly, they are still being developed for new web applications!
What’s wrong with a Gen-1 web app? Nothing. It was a great technology for the time and there are plenty of useful web apps that still function under this paradigm. But why would you want to develop a new application platform using technology essentially from the late 1990s? The reasons to avoid this will become even more apparent as you gain an understanding of the benefits of Gen-2 and Gen-3 web apps.
Examples of Gen-1 technologies include traditional ASP.NET and PHP.
Gen-2 web apps officially came onto the scene in 2006 when certain web standards needed for the technology to gain wide adoption were released in draft form. These open standards combined with the release of the iPhone, which did not run Flash, eventually led to Adobe Flash becoming an obsolete technology for web app development. You can find primitive examples of Gen-2 apps dating back to the late 1990s, but really Google Gmail and Google Maps were some of the first major products to take this approach in 2005.
The key to Gen-2 web apps is that they use a group of standard technologies and practices to create a more dynamic interaction with the user. Without getting too technical, Gen-2 web apps largely revolve around a set of technologies that are collectively called AJAX (Asynchronous JavaScript and XML).
In a nutshell, these Gen-2 web apps are still partially rendered on the server, but once they are loaded by the browser, something unique happens. In Gen-1 web apps, Javascript was primarily used to validate information before sending it back to the serve. With Gen-2 web apps, the page loads with a more robust set of Javascript code. It knows how to render certain elements of its interface on its own, independent of the server.
Consider the revisions to the illustration above (differences from Gen-1 web apps are bolded):
As such, on a Gen-2 app, if you request some more information, your web app knows how to go back to the server in the background, request just the data, and when that data is sent back, it knows how to update its own interface with that data.
This changes quite a bit. It starts to place the UI burden on the browser. The server is still responsible for generating a lot of the HTML, but the browser is now more intelligent about being able to modify its interface and it requests data updates from the server instead of requesting entire refreshes of its interface.
This has the advantage of creating much more responsive feeling apps. Data just magically appears when you request it. Your screen doesn’t flicker and refresh constantly as you’re going about your business. And since you’re only requesting data updates, you’re using less bandwidth so Gen-2 web apps feel snappier in low bandwidth situations.
AJAX web apps (what I’m calling Gen-2 web apps) led to a revolution in web application development. You could now create very robust applications in the browser that felt more like desktop applications. Think about this for a second. Before Google Gmail, you probably used a desktop email client of some sort (Outlook, Thunderbird, Apple Mail). Web based email was largely a backup just in case you were somewhere you needed quick access – but no one liked it because it felt like a web site, not a robust application. With Gmail, things started changing. Now, a large part of the population does their email exclusively through a browser.
Examples of Gen-2 technologies include things like Microsoft MVC and JQuery.
This is all overly simplified, but hopefully it has helped to surface the difference between Gen-1 and Gen-2 web apps. The next post will talk about the emerging possibilities with Gen-3 web apps.
I’d love to hear your thoughts or questions about this post. Comment below!
Over the years, I’ve had a number of opportunities to manage projects based on open source frameworks. The subject of managing these sorts of projects is vast, but in this post, I will share some of my experiences that I hope will be helpful to you. During our lifetime, the transition into the “information age”, also known as the “digital revolution”, has generated countless lines of software code. I wouldn’t even pretend to know how many total lines of code have been written, but this infographic is pretty interesting: “How many lines of code is your favorite app.” Whatever the actual number is, it’s huge. Consider how much effort went into writing that code. That’s a lot of value that’s been created over the years, but most of it is isolated, not accessible, and eventually lost.
This is the beauty of open source software. A complex piece of software can easily get into the hundreds of thousands to millions of lines of code. In many cases, companies are solving similar problems independently, over and over again. This is a massive waste of effort. Once companies started to realize that they could build upon a shared body of code rather than reinventing or purchasing expensive proprietary solutions, it only made sense that open source software would become a big deal. As a result, over the last 15 to 20 years open source software has become a major movement in the IT industry. The movement’s influence has grown so vast that open source projects like Linux have given their proprietary counterparts, for example Windows, a real run for their money. In fact, even Apple’s OSX operating system is based on a Unix derivative that Apple open sourced called Darwin — which borrows from another open source tradition of operating systems called BSD! More recently, Microsoft and Apple have announced that they are open sourcing their respective development technologies, dotNet and Swift. The value of cooperating around open source projects and collaboratively solving complex problems has obviously proven itself.
Olive Technology has been developing custom softwares for our customers for almost 20 years and we have been very fortunate to be part of this open source movement. In fact our open source teams had been instrumental in setting up a Drupal chapter in the city of Hyderabad, which is one of the major software hubs in the world. We periodically support the open source forums and seminars that are conducted in and around the city.
One of the reasons we have been proponents for projects that are developed on open source frameworks is the benefits our clients get from the support of large online developer communities. This support ensures that our clients’ projects will be viable well into the future, even without Olive Technology. For that reasons, we argue that one of the criteria for selecting an open source framework should be its support base. You want to make sure your solution will be supported even when the people who did the initial development work are long gone.
For most of the open source frameworks, advanced features can only be achieved through custom code. Much of this code doesn’t get shared in the community as the customizations belong to the client. So companies end up “reinventing the wheel”. Ideally, companies would identify those customizations that aren’t deeply proprietary so as to release those customizations back to the open source community so that others could benefit from the customizations in the same way that the company benefited from the tremendous amount of free code they used as the foundation for their customizations. If you use open source, here’s a golden rule we ought to live by: give your code unto others as you would have them give their code unto you… or something like that.
I’ll close with a few pointers for a project manager who plan to work with open source frameworks:
Hopefully this information is of some use to you. If you want to have a candid discussion about how open source solutions may benefit your project, reach out to us and let’s talk shop.
India is a nation on the rise. Its ascension into the international technology scene since the 1990s has helped to bolster a sizeable middle class. But in the midst of that, there are still many in need. The reality is that there are many in need all over the world. You don’t have to work in India to find those who could use the help of their community. A group that is often forgotten throughout the world, is one of the most vulnerable: orphaned children.
Throughout the year, the community of Olive Technology pulls together our resources and we raise money to help those around us. Recently, the team had the blessing of helping to support a local orphanage in Hyderabad, Sneha Sadan Orphanage. It’s always hard to gauge who gets more out of these sorts of visits – the kids, or the adults. Regardless, everyone had fun that day.
Something that’s been true about Olive technology since the beginning is that being a community is about more than just having fun at work – it’s about making a difference in the world around us.
We live in a connected world where information is abundant, travels fast and changes rapidly. We have come to expect our interaction with digital devices to also be instantaneous. The world around us is expected to respond at “the click of a button.”
I will not venture to comment on the effects of such a low attention span, ponder over the futility of seeking instant gratification, or preach about the virtues of patience. Instead, let me focus on a key principle that we must internalize in order to be successful technology builders and providers in today’s environment. I believe it is important to release a technology product quickly, sometimes at the cost of compromising on our sense of its perfection. When it comes to technology development, I believe speed beats perfection.
This is true especially for web and mobile apps. Since they are, by definition, cloud based, it is possible to release new versions as frequently as needed since devices are almost always connected to the Internet cloud. Updates, improvements and enhancements can and should be made continuously to reach higher standards of quality, ease of use and increased functionality.
The definition of perfection keeps changing as the devices become faster, better and more intuitive. So, release your first version and keep on improving in order to keep up with advances in the hardware-software platform on which it runs.
Finally, speed beats perfection because the competition is on the heels of every successful product and you have to increase speed to market, or risk losing the market.
