Programming languages and the GUI

Programming languages and GUIs don't mix. Of all the languages available today, none are GUI-based languages.

My test for a GUI-based language is the requirement that any program written in the language must use a GUI. If you can write a program and run it in a text window, then the language is not a GUI-based language.

This is an extreme test, and perhaps unfair. But it shows an interesting point: We have no GUI-based languages.

We had programming before the GUI with various forms of input and output (punch cards, paper tape, magnetic tape, disk files, printers, and terminals). When GUIs came along, we rushed to create GUI programs but not GUI programming languages. (Except for Visual Basic.) We still have GUIs, some thirty years on, and today we have no GUI programming languages.

Almost all programming languages treat windows (or GUIs) as a second thought. Programming for the GUI is bolted on to the language as a library or framework; it is not part of the core language.

For some languages, the explanation is obvious: the language existed before GUIs existed (or became popular). Languages such as Cobol, Fortran, PL/I, Pascal, and C had been designed before GUIs appeared on the horizon. Cobol and Fortran were designed in an era of magnetic tapes, disk files, and printers. Pascal and C were created for printing terminals or "smart" CRT terminals such as DEC's VT-52.

Some languages were designed for a specific purpose. Such languages have no need of GUIs, and they don't have any GUI support. AWK was designed as a text processing language, a filter that fit in with Unix's tool-chain philosophy. SQL was designed for querying databases (and prior to GUIs).

Other languages were designed after the advent of the GUI, and for general-purpose programming. Languages such as Java, C#, Python, and Ruby came to life in the "graphical age", yet graphics is an extension of the language, not part of the core.

Microsoft extended C++ with its Visual C++ package. The early versions were a daunting mix of libraries, classes, and #define macros. Recent versions are more palatable, but C++ remains C++ and the GUI parts are mere add-ons to the language.

Borland extended Pascal, and later provided Delphi, for Windows programming. But Object Pascal and Windows Pascal and even Delphi were just Pascal with GUI programming bolted on to the core language.

The only language that put the GUI in the language was Visual Basic. (The old Visual Basic, not the VB.NET language of today.) These languages not only supported a graphical display, they required it.

I realize that there may be niche languages that handle graphics as part of the core language. Matlab and R support the generation of graphics to view data -- but they are hardly general-purpose languages. (One would not write a word processor in R.)

Mathematica and Wolfram do nice things with graphics too, but again, for rendering numerical data.

There are probably other obscure languages that handle GUI programming. But they are obscure, not mainstream. The only other (somewhat) popular language that required a graphical display was Logo, and that was hardly a general-purpose language.

The only popular language that handled the GUI as a first-class citizen was Visual Basic. It is interesting to note that Visual Basic has declined in popularity. Its successor, VB.NET is a rough translation of C# and the GUI is, like other languages, something added to the core language.

Of course, programming (and system design) today is very different from the past. We design and build for mobile devices and web services, with some occasional web applications. Desktop applications are considered passe, and console applications are not considered at all (except perhaps for system administrators).

Modern applications place the user interface on a mobile device. The server provides services, nothing more. The GUI has moved from the desktop PC to the web browser and now to the phone. Yet we have no equivalent of Visual Basic for developing phone apps. The tools are desktop languages with extensions for mobile devices.

When will we get a language tailored to phones? And who will build it?

Locked out of the walled gardens

A dark side of the walled gardens of technology is becoming visible.

The old paradigm was one of home ownership. You purchased your equipment (a PC) and then you installed whatever software you wanted. You decided. There were constraints, of course. PCs typically ran Windows (or before that, DOS) and the software had to run under the operating system. PCs had various configurations and the software had to fit (a floppy-only PC could not run large software that required a hard drive, for example).

Once installed, you had to see to the care and feeding of the software. You had to ensure that updates were applied. You had to ensure that data you exchanged with other users was compatible with their systems.

The benefit of this paradigm is the open market and the freedoms that come with it. Vendors are free to enter the market and offer their wares. You are free to choose among those products. You could pick from a number of word processors, spreadsheets, databases, compilers and IDEs, project managers, and other product categories.

The walled gardens of iOS and Android (and soon Windows and MacOS X) provide a different paradigm. If the old paradigm was one of home ownership, the new paradigm is one of renting an apartment. You still have a place for your stuff, yet a lot of the tedious chores of ownership have been removed.

With Apple's walled garden of iOS (and the gatekeeper iTunes), updates are automatic, and software is guaranteed to be compatible. The same holds for Google's Android garden and its gatekeeper 'Play Store'. They guard against 'unfriendly' software.

But the price of living inside the walled garden is that one loses the open market. Only selected vendors may enter the market, and those that do may offer a limited selection of products. Apple and Google enforce requirements for products in their walled gardens, through their registration and gatekeepers. Apple forbids a number of products in iOS and limits others. Web browsers, for example, must use Apple's WebKit engine and not install their own; Apple also forbids programming languages or scripting languages.

We're now seeing the Flash technology being pushed out of the walled gardens. Apple has prohibited it from the beginning. Google has deprecated it on YouTube. How long before Microsoft kicks it out of its garden?

The expulsion of Flash may foreshadow other exclusions of technology. Apple could, at any time, remove Microsoft's apps from iTunes. Google could remove Adobe apps from the Play Store. Microsoft could kick out Oracle apps from the (soon to be revived, I think) Microsoft App Store.

The ability to remove apps from the garden is something that the enterprise folks will want to think about. Building a business on a walled garden has the risk of existing at the whim of the gardener.

Mobile operating systems break the illusion of control

The mobile operating systems iOS and Android are qualitatively different from previous operating systems like Windows, MacOS, and Linux. They break the illusion that an application has control; this illusion has been with us since the first operating systems. To understand the illusion, and how mobile operating systems are different, we must understand the origins of operating systems.

The dawn of computers saw the hardware emerge from electro-mechanical relays, but no software. The first computers were programmed with wires connecting components to other components. A computer was a custom-purpose device, designed and built to perform one calculation. Shortly after, the "programming wires" were isolated to removable boards, which allowed a "program" to be removed from the computer and stored for later use.

The first programs (in the sense we know them) were sequences of numerical values that could be loaded into a computers memory. They were a softer variant of the wired plug-board in the earlier computers. Building the sequence of numerical values was tedious; one had to understand not only the problem to be solved but also the processor instruction set. These sequences are now called "machine language".

Programmers, being what they are, developed programs to ease the chore of creating the sequences of machine language values. These programs were the first assemblers; they converted symbols into executable sequences. A programmer could work with the much easier to understand symbolic code and convert the symbols to a program when his changes were done.

Up to this point, the operation of the computer has been a simple one. Create a program, insert it into the computer, and let it run. The program instructed the computer, and the computer performed the calculations.

There were no operating systems. It was the computer and the program, alone together in the small universe of computing hardware. The program was in charge and the computer obeyed its instructions. (Blindly and literally, which meant that the programmer had to be precise and complete in his description of the operations. That aspect of programming remains with us today.)

The first operating systems were little more than loaders for programs. Programmers found that the task of loading an executable program was a chore, and programmers, being what they are, creating programs to ease that task. A loader could start with a collection of programs (usually stored in a deck of punch cards), load the first one, let it run, and then load and run the next program.

Of course, the loader was still in memory, and the loaded programs could not use that memory or overwrite the loader. If they did, the loader would be unable to continue. I imagine that the very earliest arrangement worked by an agreement: the loader would use a block of addresses and the loaded programs would use other memory but not the block dedicated to the loader. The running program was still "in charge" of the computer, but it had to honor the "loader agreement".

This notion of "being in charge" is important. It is a notion that has been maintained by operating systems -- up to mobile operating systems. More on that later.

Operating systems grew out of the concept of the loader. They became more powerful, allowing more sharing of the expensive computer. The assumed the following functions:

• Allocation and protection of memory (you can use only what you are assigned)
• Control of physical devices (you must request operations through the operating system)
• Allocation of CPU (time slices)

These are the typical functions we associate with operating systems.

Over the years, we have extended operating systems and continued to use them. Yet in all of that time, from IBM's System/360 to DEC's VMS to Microsoft's Windows, the understanding is that our program (our application), once loaded, is "in control" until it exits. This is an illusion, as our application can do very little on its own. It must request all resources from the operating system, including memory. It must request all actions through the operating system, including the operating on devices (display a window on a screen, send text to a printer, save a file to disk).

This illusion persists, I believe due to the education of programmers (and system operators, and computer designers). Not merely through formal training but also through informal channels. Our phrases indicate this: "Microsoft Word runs and prints a document" or "Visual Studio builds the executable" or "IIS serves the HTML document". Our conversations reinforce the belief that the running computer is in control.

And here is where the mobile operating systems come in. Android and iOS have very clear roles for application programs, and those roles are subservient to the operating system. A program does not run in the usual sense, making requests of the operating system. Instead, the app (and I will use the term "app" to indicate that the program is different from an application) is activated by the operating system when needed. That activation sees the operating system instruct the app to perform a task and then return control to the operating system.

Mobile operating systems turn the paradigm of the "program in control" inside-out. Instead of the program making requests of the operating system, the operating system makes requests of the program. The operating system is in control, not the program.

This view is very different from our traditional view, yet it is an accurate one. Apps are not in control. Applications are not in control -- and have not been for many years.

The convergence of web and mobile

It's easy to think of web applications and mobile applications as two distinct entities (or two distinct collections of entities). Web applications are hosted on web servers in data centers and they "run" in a browser. Mobile apps are installed on smartphones and tablets and run on those devices. Web applications are large, complex things and mobile apps are small and easy to use. Web applications are general, running on all major web browsers, and mobile apps are built for specific platforms (iOS, Android, etc.).

Yet the two are converging. Mobile apps are becoming more like web applications, and web applications are becoming more like mobile apps.

Let's start with mobile apps. The "standard model" for an app is a small, lightweight user interface that talks to services on back-end servers. In that sense, a mobile app is very much like a web application, which is a web page that sends requests to back-end servers.

The "standard model" for mobile apps is also that the app is installed once on your device and there it sits, ready for you to use. That's not really true, at least not with many of the apps I use.

The app does sit on my phone, but apps are upgraded frequently. The "good old days" of PC applications (or mainframe applications) saw upgrades to applications on an annual frequency, sometimes longer. Today's mobile apps are updates monthly, and sometimes more frequently. It seems that Twitter sends updates every week!

The upgrades are usually automatic and silent, requiring no intervention from the operator. One can tell when an app has been upgraded (sometimes), because when they display a small "what's new" dialog. A few apps are upgraded more often than I actually use them. I know this because I always see the "what's new" dialog when I run the app.

With upgrade frequencies weekly and approaching daily, perhaps it doesn't make sense to install the app on the phone. That is, perhaps it makes more sense to always download the app from the server. In this way, a mobile app is becoming more like a web page, which is always downloaded from the server. (I'm ignoring cached copies.)

Looking at web applications, we can see changes that make them more like mobile apps. The "standard model" for a web application is that it lives in the browser and has access to only the back-end servers, with no abilities to manipulate data or devices on the host computer. Yet this is no longer true: web apps can upload files, send e-mail (or tie in to local e-mail clients), and now manipulate the local camera and attached devices.

Web applications are becoming more like mobile apps. Mobile apps are becoming more like web applications. Perhaps we will meet in a convenient, happy middle ground that lets us get the best of both worlds.

Mobile devices may always be independent from corporate bureaucracy

The mobile revolution is different from the PC revolution.

The PC revolution saw the IBM PC adopted as the standard for personal computing. It was adopted by businesses and consumers, but most spending was from businesses.

The mobile revolution, in contrast, is driven by consumers. Individuals are buying smart phones and tablets. Businesses may be purchasing some mobile devices, but the bulk of the spending is on the consumer side.

Why is this distinction important?

To answer that, let's look at PCs and their history. Personal computers in corporations are anything but personal. They are purchased by the corporation and controlled by the corporation. The people using PCs rarely have administrator privileges for those PCs. Instead, the ability to install software and make significant changes is governed by the local copy of Windows and configurations in a central ActiveDirectory server.

The infrastructure of ActiveDirectory and Windows group policies was not built overnight, and was not part of the original PC. The first PCs ran PC-DOS and had no administrative controls at all -- any user could do anything, see anything, and change anything. Microsoft worked on PC-DOS for IBM, then MS-DOS for non-IBM computers, then Windows, and finally server software and ActiveDirectory. It took about twenty years to create, from the introduction of the IBM PC in 1981 to the introduction of ActiveDirectory in 1999.

That work was done by Microsoft because corporations wanted it. They wanted mechanisms to control the PCs and the access to data on PCs and servers. (And even with all of that interest, it took two decades to "enterprise-ify" PCs and make them part of the bureaucracy.)

Corporations were interested in PCs from the introduction of the IBM PC. (Some corporations were interested in earlier microcomputers, but they were a minority.) Corporations were interested in PCs because PCs ran Lotus 1-2-3, the popular spreadsheet at the time.

Now let's look at mobile devices. Corporations have a mild interest in mobile devices. It is only a fraction of the interest in PCs. There is no killer app for tablets, no must-have app for smart phones. (At least, not for corporations.) It is quite possible that phones and tablets are too personal for corporations.

It is telling that the Microsoft Surface tablet, with its ready-to-use connections to ActiveDirectory, has seen little interest. For consumers, the Surface (and other Windows tablets) are more expensive and not as useful as the iPad and Android tablets. But even corporations have little interest in the Microsoft offerings.

Without corporate interest (and corporate spending), neither Apple nor Google have incentive to make their tablets "safe for the enterprise" -- that is, controlled through a central administration point. (Yes, there are "mobile device management" packages, but they have little interest.)

Apple and Google will invest their efforts in other areas, such as better hardware and improved reliability of apps in their stores (and maybe higher profits).

Corporations will use tablets for small, isolated projects, if at all. I suspect most corporations view their proven and familiar desktops and laptops as sufficient, with little benefit from tablets.

But all is not lost for tablets and smart phones. Some folks will use them for critical business purposes. These folks will not be the large corporations with established IT infrastructure. They will be the start-ups, the small companies who will build completely new apps to solve completely new business problems.

Mobile apps don't need tech support

I recently "fired" the New York Times. By "fired", I mean that I cancelled my subscription. The reason? Their app did not work on my Android tablet.

The app should have worked. I have a modern Android tablet running Android 4.1 and Google Play services. (I can understand the app not working on a low-end Android tablet that is not certified for Google Play services. But this was not my situation. The app should have worked.)

The app failed -- consistently, and over a period of time. It wasn't a simple, one-time failure. (The app worked on my Android smart phone, so I know my account was in good standing.)

So I uninstalled the app and cancelled my subscription.

A few musings on software and tech support.

Cost A software package for Windows is an expensive proposition. Most software -- software that is sold -- costs upwards of hundreds of dollars. Most enterprise software has not only a purchase cost but a support cost -- an annual fee. With such an investment in the software, I will only discard the software when I must. I have a strong incentive to make it work.

The tech support experience Software companies have, over the years, trained us lowly users to expect an unpleasant experience with technical support. Software companies hide the phone number, pushing you to their web-based documentation and support forum. If you do manage to call them, you are greeted with a telephone "torture menu" and long wait times. (But with a significant investment in the software, we are willing to put up with it.)

The equation changes for mobile apps Mobile apps are much less expensive than PC applications. Many are free, some cost a few dollars.

Customer expectations may be shaped by many things. Software is not always an expensive proposition. Consider:

• The (relatively) low cost for Mac OS
• The appearance of Linux (a free operating system)
• Open source applications (also free)
• Free apps for your smartphone
• Free e-mail from Google and Yahoo
• Unlimited voice and text with your cell phone plan.

While I may be willing to wait on the phone for a (probably polite but ineffective) support technician when the software cost is high, I am not willing to invest that time for free or cheap software.

I suspect that there are several doctoral theses in this phenomenon, for students of either psychology or economics.

I decided rather quickly to drop the app for the New York Times. The failing app was a frustrating experience, and I wanted to move on to other things. I may have posted about it on Twitter; I dimly remember a response from the Times folks claiming that their support team could help me. But by the time I got that response, I had already fired them.

Regardless of the economics and the psychology, the message for app makers is clear: Your app must work, with a quality higher than most PC applications. It must work and be simple enough that a person can use it without a manual, without a help system, and without a technical support team.

If it doesn't, your customers will delete the app and walk away. Your revenue from app upgrades or connected services (in my case, the subscription to the New York Times) will drop. You do not get a chance to "save" a customer when they call for support -- they're not going to call.

The Mobile Evolution is different from the PC Revolution

When PCs entered the scene, it was a revolution. The entry of mobile devices (smartphones and tablets) is less revolution and more evolution.

What is the difference? Exclusive applications.

When PCs entered the market, they shared some applications with minicomputers and mainframes (assemblers, compilers, and text editors, mostly) but a large percentage of applications were unique to PCs. Word processors, spreadsheets, and games were the popular applications, and none of them were from mainframes.

Mobile applications, for the most part, are extensions of existing PC and web applications. Twitter, Facebook, even Google Maps all live on the web and in the mobile world.

There are some apps that are (or were) mobile-only. "Angry Birds" was first released for the iPhone and later moved to other platforms. FourSquare is a mobile-only app, given its "check in" function.

But the number of mobile-only apps is small, compared to the total. This is quite different from the PC revolution, which saw thousands of PC-specific applications and a small number of mainframe "crossover" applications.

The PC world was filled with new applications, and new types of applications. That's why it was a revolution. The mobile world -- so far -- is filled with extensions to web applications. That's why the mobile world is an evolution.

The New Aristocracy

The workplace is an interesting study for psychologists. It has many types of interactions and many types of stratifications of employees. The divisions are always based on rank; the demonstrations of rank are varied.

I worked in one companyin which rank was indicated by the type, size, and location of one's workspace. Managers were assigned offices (with doors and solid walls), senior technical people were assigned cubicles next to windows, junior technical employees were assigned cubicles without windows, and contract workers were "doubled up" in windowless cubicles.

In another company, managers were issued color monitors and non-managers were issued (cheaper) monochrome monitors.

We excel at status symbols.

The arrival of tablets (and tablet apps) gives us a new status symbol. It allows us to divide workers into those who work with keyboards and those who work without keyboards. The "new aristocracy" will be, of course, those who work without keyboards. They will be issued tablets, while the "proletariat" will continue to work with keyboards.

I don't expect that this division will occur immediately. Tablets are quite different from desktop PCs and the apps for tablets must be different from desktop apps. It will take time to adapt our current applications to the tablet.

Despite their differences, tablets are -- so far -- much better at consuming information, while PCs are better at composing information. Managers who use information to make decisions will be able to function with tablets, while employees who must prepare the information will continue to do that work on PCs.

I expect that the next big push for tablet applications will be those applications used by managers: project planning software, calendars, dashboards, and document viewers.

The new aristocracy in the office will be those who use tablets.

The end of complex PC apps

Businesses are facing a problem with technology: PCs (and tablets, and smart phones) are changing. Specifically, they are changing faster than businesses would like.

Corporations have many programs that they use internally. Some corporations build their own software, others buy software "off the shelf". Many companies use a combination of both.

All of the companies with whom I have worked wanted stable platforms on which to build their systems and processes. Whether it was a complex program built in C++, a comprehensive model built in a spreadsheet, or an office suite (word processor, spreadsheet, and e-mail), companies want to invest their effort in their custom solutions. They did not want to spend money or time on upgrades and changes to the operating system or commercially available applications.

While they dislike change, corporations are willing to upgrade systems. Corporations want long upgrade cycles. They want gentle upgrade paths, with easy transitions from one version to the next. They were happy with the old Microsoft world: Windows NT, Windows 2000, and Windows XP were excellent examples of the long, gentle upgrades desired by corporations.

That is no longer the world of PCs. The new world sees fast update cycles for operating systems, major updates that require changes to applications. For companies with custom-made applications, they have to invest time and effort in updating their applications to match the new operating systems. (Consider Windows Vista and Windows 8.) For companies with off-the-shelf applications, they have to purchase new versions that run on the new operating systems.

What is a corporation to do?

My guess is that corporations will seek out other platforms and move their apps to those platforms. My guess is that corporations will recognize the cost of frequent change in the PC and mobile platforms, and look for other solutions with lower cost.

If they do, then PCs will lose their title to the development world. The PC platform will not be the primary target for applications.

What are the new platforms? I suspect the two "winning" platforms will be web apps (browsers and servers), and mobile/cloud (tablets and phones with virtualized servers). While the front ends for these systems undergo frequent changes, the back ends are relatively stable. The browsers for web apps are mostly stable and they buffer the app from changes to the operating system. Tablets and smart phones undergo frequent updates; this cost can be minimized with simple apps that can be updated easily.

The big trend is away from complex PC applications. These are too expensive to maintain in the new world of frequent updates to operating systems.

More was more, but now less is more

IBM and Microsoft built their empires with the strategy "bigger and more features". IBM mainframes, over time, became larger (in terms of processor speed and memory capacity) and included more features. Microsoft software, over time, became larger (in terms of capacity) and included more features.

It was a successful strategy. IBM and Microsoft could win any "checklist battle" which listed the features of products. For many managers, the product with the largest list of features is the safest choice. (Microsoft and IBM's reputations also helped.)

One downside of large, complicated hardware and large, complicated software is that it leads to large, complicated procedures and data sets. Many businesses have developed their operating procedures first around IBM equipment and later around Microsoft software. When developing those procedures, it was natural to, over time, increase the complexity. New business cases, new exceptions, and special circumstances all add to complexity.

Businesses are trying to leverage mobile devices (tablets and phones) and finding that their long-established applications don't "port" easily to the new devices. They are focussing on the software, but the real issue is their processes. The complex procedures behind the software are making it hard to move business to mobile devices.

The user interfaces on mobile devices limit applications to much simpler operations. Perhaps our desire for simplicity comes from the size of the screen, or the change from mouse to touch, or from the fact that we hold the devices in our hands. Regardless of the reason, we want mobile devices to have simple apps.

Complicated applications of the desktop, with drop-down menus, multiple dialogs, and oodles of options simply do not "work" on a mobile device. We saw this with early hand-held devices such as the popular Palm Pilot and the not-so-popular Microsoft PocketPC. Palm's simple operation won over the more complex Windows CE.

Simplicity is a state of mind, one that is hard to obtain. Complicated software tempts one into complicated processes (so many fonts, so many spreadsheet formula operations, ...). Mobile devices demand simplicity. With mobile, "more" may be more, but it is not better. The successful businesses will simplify their procedures and their underlying business rules (perhaps the MBA crowd will prefer the words "streamline" or "optimize") to leverage mobile devices.

Migrating from desktop to cloud is no small deal

The popularity of smart phones and tablets has made mobile (and its server-side colleague cloud) the new darling technology. They are the new buzzwords that garner attention -- and probably funding. They get attention for new apps, and some folks have been migrating existing desktop and web apps.

If you are embarking on such a project, I encourage you to look into three technologies: mobile devices, cloud computing, and functional programming.

Functional programming is a specific way of designing programs, much like structured programming and object-oriented programming. But in contrast to those techniques, functional programming guides one to smaller units of code. Structured programming and object-oriented programming allow one to build small units, but do not encourage it. As a result, most (non-homework) code built with structured and object-oriented techniques contains collections of large modules and objects.

Cloud computing is a specific way of designing systems out of smaller components, many of which are part of the cloud infrastructure. Cloud-based applications use data stores, message queues, and a measured amount of code. (Previous architectures such as desktop and web often saw applications made of whole cloth with little use of pre-made components.)

Mobile devices force a split of code between the server (typically a cloud-based server) and the user interface on the device. The device usually performs some processing with most occurring on the server. (A few apps perform all processing on the device, such as in the game "Angry Birds". But they are exceptions.) Splitting the code between the device and the server forces you to build not a single application but two programs that communicate.

The new technology set encourages us to build systems of smaller programs. Mobile/cloud is for collaborating programs, not monolithic ones. Functional programming techniques reward small programs and penalize large ones.

This "impedance mismatch" between mobile/cloud and desktop applications (and to a somewhat lesser extent, web applications) means that porting to mobile/cloud is difficult. The legacy systems on the earlier platforms were built to take advantage of the strengths of the platform, and small, collaborating programs were not efficient.

The mismatch between object-oriented systems and functional programming is even greater. Object-oriented programming is often about objects holding state -- mutable state, so that objects change over time -- and functional programming is about immutable objects.

A few well-designed (from the mobile/cloud perspective) applications for the desktop and web can be migrated to mobile/cloud. Most, I think, will be difficult. Some may be close to impossible.

My advice: Build some new apps for mobile/cloud, to gain experience with the new design paradigm. Try out the functional programming languages (or at least, your favorite object-oriented language is with immutable objects). Once you have that experience, evaluate your legacy apps and select a small number (perhaps two) of "easy" apps for migration. I'm sure that the exercise will give you greater insight into the effort for the other (more difficult) legacy apps.

Then, armed with experience of the new technologies and a good understanding of your code base, should you migrate from desktop to mobile/cloud.

Leaping to mobile may be better than fixing a web site

When looking at the changes needed to make a web site suitable for mobile devices, it may be better to write native apps.

ADP, the large payroll processor, has a web site. It was designed several years ago, and is a bit dated. Not as old as a 1990's style web page with blink tags, but not as modern as it could be. It uses a plug-in to display data enclosed in a PDF. (I find that a bit odd, given that HTML is all about markup and presentation -- but that's not important right now.) The important bit: that plug-in fails on some configurations.

The web site works on my laptop (IE on Windows 7) and on my Apple MacBook (an old version of Safari on an equally old version of MacOS). The web site fails on Chrome on Ubuntu, but works on FireFox on Ubuntu.

The web site works in Windows 8, when I load it in the "classic desktop" version of IE. It fails when I load it in the "Metro" version of IE.

These failures are due to the plug-in (or lack thereof). Chrome under Ubuntu cannot find the plug-in to handle a PDF file. (Despite my various attempts.)

Now, I realize that the market share for Chrome on Ubuntu is quite small. I'm not seriously thinking that ADP would modify a web site to handle that small slice of the market.

But what about Windows 8?

The "Metro" version of IE does not support plug-ins -- of any kind. This web site will never work on the "Metro" side of Windows 8. (Or, I suspect, any future version of Windows.) While it does work on the "classic desktop" side (Windows 8 has two versions of IE, one for "Metro" and the other for "classic") it does not work on Windows RT. (And Windows RT has only the "Metro" version of IE.)

One would think that ADP would update their web site to handle this problem.

Or maybe not.

They have a mobile app. Two, actually: one for iOS and one for Android. (I suspect that ADP is developing a third for Windows RT.)

Native apps solve the problem of plug-ins. They solve other configuration issues. And they solve the problem of compatibility with old browsers.

Perhaps this is the right approach. If it is, then ADP will probably leave their web site in its current ("broken" as I see it) state. Is that a problem? Well, maybe, for a small number of users. (A Windows RT version of the app will solve the Windows 8 problems.)

I think we may see a shift from web development to mobile development. Web sites won't go away, but they won't be the premiere interface either. They will be a legacy interface, with mobile taking the lead.

The politics of mobile apps

The politics of mobile apps are different from the politics of desktop and web apps.

Desktop and web apps can expand "forever". There are no practical limits to the number of dialogs one can add to a desktop application. There is no limit to the number of web pages on can include in a web application.

Mobile apps, unlike desktop and web apps, have limits on their functionality. These limits are set by the device and our expectations of mobile apps - an app on a smart phone can be only so complicated. Part of the limit comes from the screen size. The other limit comes from our ideas of mobile apps. We expect easy-to-use apps that "just do it".

What this means for development teams is that a mobile app may expand until it reaches that (nebulous) limit of complexity. At some point the app becomes Too Complicated. At that point, no features may be added -- unless you remove or simplify other features.

What this means for the managers of the development team is that the process to select features for a mobile app is very different from the process to select features for a desktop or web app.

The limits on development of these apps are not complexity, but team resources (and indirectly, money). A team can add features to desktop and web apps, and the constraint is the team size and the ability to test and deploy the new features. Development teams can be expanded, with additional funding. Test teams can be expanded. Deployment and support teams can be expanded. Funding can even overcome the limit of the building that houses the development team -- with enough money one can lease (or construct) another building.

The politics behind desktop and web applications are well known within organizations. The typical organization will have a committee (or perhaps a single person) who gathers requests for new features, assigns priorities, and feeds them to the development team. This committee acts as a regulator on requirements, and prevents the need for expansion of the teams (and hence limits the expense of the teams).

Discussions about feature selection and priorities may become heated as individuals disagree. Yet underneath the debate and the arguments is the understanding that all features can be accommodated, given enough time. If your request is not granted for one release, it is possible that it will be included in a later release. This understanding provides a level of civility in the discussions.

The politics for mobile apps is different. With hard limits on a feature set, there is no guarantee that a requested expansion will be included -- even eventually. Once a mobile app reaches a level of complexity that discourages customers, the app is essentially "full". Adding features to the app will drive away customers (and business).

The selection of features for a mobile app becomes a zero-sum game: features can be added only by removing others. This means that some requests will win and other will lose. And lose not in the "maybe for the next release" sense, but in the harder "not now and not ever" sense.

Once people realize this, they will fight much harder for their features. The debates and arguments about features will be more heated and possibly unpleasant, depending on the culture of the organization.

Savvy organizations will prepare for this change in politics. I can see three changes:

• Designate individuals or committees to define the user experience. These individuals will oversee the app design and review all features.
• Change the processes for feature requests to specify business benefits, preferably in terms of revenue or expense reduction. Also, define processes to hold requesters to their earlier estimates.
• Provide training for negotiation and conflict resolution.

The organizations that prepare for this change will be in a better position to move to mobile apps.

Limits to growth in mobile apps

Application development, at least in the PC era, has followed a standard pattern: start with a basic application, then issue new versions with each new version containing more features. Once released, an application has only one direction in terms of complexity: up.

This increase in complexity was possible due to improving technology (powerful processors, more memory, higher screen resolutions, faster network connections) and necessary due to competition (in some markets, the product with the larger checklist of features wins).

The pattern of increasing the complexity of an application has been with us since the very first PC applications (which I consider Wordstar, Microsoft BASIC, and Visicalc). I suspect that the pattern existed in the minicomputer and mainframe markets too.

The early era of microcomputers (before the IBM PC in 1981) had hard limits on resources. Processors were only so fast. You had only so much memory. Hobbyist computers such as the COSMAC ELF had tiny processors and 256 bytes of memory. (Notice that the word 'bytes' has no letter in front.) The complexity of applications was limited by hardware and the cleverness of programmers.

PC technology changed the rules. Hardware became powerful enough to handle complex tasks. Moreover, the design of the IBM PC was expandable, and manufacturers provided bigger and more capable machines. The limit to application growth was not the hardware but the capacity of the development team. Programmers needed not to be clever but to work in teams and write easily-understood code.

With the expansion of hardware and the expansion of development teams, the bounding factor for software was the capacity of the development team. This bounding factor eventually changed to the funding for the development team.

With funding as the limiting factor, a company could decide the level of complexity for software. A company could build an application as complex as it wanted. Yes, a company could specify a project more complex than the hardware would allow, but in general companies lived within the "envelope" of technology. That envelope was moving upwards, thanks to the PC's expandable design.

Mobile technology changes the rules again, and requires a new view towards complexity. Mobile phones are getting more powerful, but slowly, and their screens are at a practical maximum. A smart phone screen size can be a maximum of 5 inches, and that is not going to change. (A larger screen pushes the device into tablet territory.)

Tablets also are getting more powerful, but also slowly and their screens are also at a practical maximum. A tablet screen can be as large as 10 inches, and that is not going to change. (A larger screen makes for an unwieldy tablet.)

These practical maximums place limits on the complexity of the user interface. Those limits enforce limits on the complexity of the app.

More significantly, the limits in mobile apps come from hardware, not funding. A company cannot assume that they can expand an app forever. The envelope of technology is not moving upwards, and cannot move upwards: the limits are cause by human physiology.

All of this means that the normal process of application development must change. The old pattern of a "1.0 release" with limited functionality and subsequent releases with additional functionality (on a slope that continues upwards) cannot work for mobile apps. Once an app has a certain level of complexity, the process must change. New features are possible only at the expense of old features.

We are back in the situation of the early microcomputers: hard limits on application complexity. Like that earlier era, we will need cleverness to work within the limits. Unlike that earlier era, the cleverness is not in memory allocation or algorithmic sophistication, but in the design of user interfaces. We need cleverness in the user experience, and that will be the limiting factor for mobile apps.

The next ERP is a private App Store

The BYOD initiatives in corporations have been treating mobile devices (smart phones and tablets) as small PCs (typically small Windows PCs). They must be managed because corporate data is confidential and must remain within the corporation. A valid reason, but the wrong conclusion.

Instead of thinking of smart phones and tablets as small PCs, we should think of them as smart phones and tablets. That is, we should think of them as devices that run apps, and corporations should provide apps to access data and perform business functions. The apps should authenticate the user, retrieve and store data (only on servers, not on the device), and govern the use and access to data.

In such a system, a corporation needs a way to build and distribute its custom apps. Common functions like e-mail and calendars can be handled with generic apps. Functions that are specific to the business must be developed by the business and somehow distributed to users.

One could put them on the public stores (Apple's iTunes, Google's Play, and Microsoft's App sStore) or one could put them on a private store. The latter may have more appeal to large organizations.

Using a store (public or private) and the existing update infrastructure simplifies the task of software distribution. New employees can go to the store and download what they need. Updates are pushed to current users.

(Using authentication -- and not apps -- to control access to data lets anyone have any app. You do not have to limit apps to employees, or even subgroups such as executives. Think of it like Microsoft Excel -- anyone can buy MS Excel but only those people who can read the corporate spreadsheets can see their contents.)

Building a private store has some advantages. It is a single point for all apps, including apps across platforms. The Apple, Google, and Microsoft stores are limited to their platfoms. A private corporate app store is a "one stop" source. Also, one is not beholden to the whims of the store managers -- all have removed apps for unknown reasons, at one time or another.

Building an app store is not a company's main purpose. (Unless the company is selling apps to all comers.) Look for the big consultancies to offer app store services and frameworks. IBM, HP, Dell, and even folks like Accenture and Booze-Allen-Hamilton may offer them. I also suspect that there will be an open-source app store framework.

I expect that app stores will be limited to large enterprises. Small Mom-and-Pop shops don't need an app store to control and measure app usage. The Fortune 500 will use them, and the next tier may, but below that the public stores may be sufficient. The market for app store frameworks and implementations may be narrow, like the ERP market.

Come to think of it, the ERP vendors may be the first of offer app store frameworks and support.

Life without files

Mobile devices (tablets and phones) are different from PCs in that they do not use files. Yes, they have operating systems that use files, and Android has file managers which let you access some or all files on the device, but the general experience is one without files.

The PC experience was centered around files. Files were the essential element of a PC, from the boot files to word processor documents to temporary data. Everything was stored in a file. The experience of using a PC was running an application, loading data from a file, and manipulating that data. When finished, one saved the information to a file.

Unix (and Linux) also have this approach. Microsoft Windows presented data in a series of graphical windows, but it stored data in files. The "File" menu with its options of "New", "Open", "Save", "Save As", and "Exit" (oddly) were standard in the UI.

The mobile experience relies on apps, not files. The user runs an app, and the app somehow knows how to get its data. Much of the time, that data is stored in the cloud, on servers maintained by the app provider. There is no "File" menu -- or any menu.

Shifting the experience from files to apps is a subtle but significant change. One tends to miss it, since keeping track of files was tedious and required discipline for structuring directories. When apps load their data automatically, one doesn't really mind not worrying about file names and locations.

With the "loss" of files, or more specifically the access to app data outside of the app, one is more conscious of sharing information between apps. In the PC age, one didn't share information between applications -- one stored data in a public place and let other applications have their way with it.

This "data available to all" makes some sense, especially for developers. Developers use multiple tools on their data -- source code -- and need it shared liberally. Editors, compilers, debuggers, lint utilities, and metrics tools all need unfettered access to the source code.

But the "free for all" model does not work so well for other data. In most shops, data is used in a single application (most often Microsoft Word or Microsoft Excel) and occasionally sent via e-mail to others. But this latter act is simply sharing the data; a better way to share data could eliminate a lot of e-mails.

Sharing data and allowing others to update it (or not) requires an infrastructure, a mechanism to make data available and control access. It requires data to be structured in a way that it can be shared -- which may be different from the internal format used by the app. Yet defining an external format may be good for us in general: we can eliminate the task of reverse-engineering proprietary file formats.

Life without files. Because we want to get work done, not read and save files.

No help for mobile apps

A big change from PC application to mobile app is the 'help' feature. Not the addition of the feature, but the removal of it.

"Help" is a distinguishing characteristic of PC and Mac applications. All modern applications have it, and most have the dual-mode 'general' help and 'context' help. The Microsoft guidelines for well-behaved Windows applications specify the "Help" menu and the "About" information. (Possibly because Apple's specifications for well-behaved Macintosh applications specify them.)

The concept of on-line help precedes Windows and Mac software. The venerable Wordstar program offered help (on-line help) in its menu configuration. Unix has provided the 'man' utility for decades.

Yet look at any mobile app and you will see no help feature. It is not a menu option. It is not a button or a hidden screen.

Apps for smart phones and tablets do not have help. And they don't need it.

This is a big change.

I can think of a few reasons that mobile apps have dropped the 'help' feature:

Single-screen focus PC help is designed for multi-window displays. Mobile apps are designed to display on the whole screen. iOS and Android enforce this; Windows RT allows for two apps to display but not an app and its help screen. When the app takes the screen, there is no room for help messages. Switching from the main app to the help app might be too much of an inconvenience.

No example There is no reference app that uses help. All of the apps run without help, and new apps copy the designs of the existing apps.

Simplicity of operation Mobile apps are designed to be simple. So simple that help is not needed. The user can operate the software without the help of help.

Of these reasons, I prefer the last. Toggling between an app and a help screen is awkward but possible. Allocating a portion of the screen to help is also possible; many apps allocate space to advertisements.

I like to think that mobile apps need no help because they are easy to use. This easy comes in two forms: ease of operations and ease of understanding the concepts. Services such as Twitter and Facebook provide easy-to-use apps that manipulate a relatively simple set of data. The concepts they use are easy to grasp.

If this is the reason, then we have an interesting aspect of mobile apps: they must be simple enough that they can be used by the average person with no help. That is, there is an upper bound on the complexity of the app. Photoshop and Visual Studio will never be mobile apps, at least not in their current forms.

As applications migrate from desktop to web to mobile, they must become simpler. (Web apps, like mobile apps, have dropped the 'help' feature.) If my theory is correct, then we should see the mobile versions of apps like Microsoft Word and Excel existing as simpler versions of their desktop PC counterparts.

I keep saying 'simpler', but that should not mean 'less powerful'. We may see some reduction in capabilities, but I suspect the big changes will be to the user interface and the techniques we use to manipulate data.

New dimensions in system design

The technology environment is changing. The change is significant, affecting the basic dimensions with which we measure systems.

The center of the old technology world was Windows. Manufacturers built PCs to run Windows. Suppliers built software to run on Windows. Systems were local -- that is, they ran in a single location. Before the internet era, everything lived in your data center. Even with the internet, systems ran in a single data center. (Or possibly two, for redundancy.)

With everything in one data center,  

The age of "Windows as the center of the universe" has passed. Today, we have multiple environments. The simple universe of one technology has been replaced by a universe of multiple galaxies.

Today, systems that are spread across multiple hardware installations. Systems consist of one (or several) front end "user clients", possibly for the iPhone, Android phones, and web browsers. The back end consists of not one but many cooperative services, each handling a small portion of the work. These can include web servers, database servers, queue managers, and content distribution networks.

But the change is larger than that. The set of basic elements is changing. In the old world, systems were built from a database, access, and programs written in a specified language. Those "dimensions" of the application defined its "space" in the data center. Vendors were defined by how well they met the needs of the organization in those dimensions.

In the new world, systems are more complex. Instead of a single database, a system may use several. Instead of a single web server, an application may use multiple, depending on the transaction being processed. We use virtualized processors to host servers, and cloud computing to manage the virtualized servers. We no longer think of a system as "a Java application"; we think of it as "a Java, Javascript, SQL, NoSQL, message queues, and some HTML and CSS" system.

In such a complex world, we design our systems with a new collection of "building blocks", and we look for vendors to provide those building blocks. Those elements of system design are: hardware, software, content, and services. These are the dimensions for system architecture and vendor offerings.
Let's look at the big providers:

Microsoft clearly supplies software: Windows, Office, Visual Studio, and many other packages. They are getting into the hardware game. Microsoft has offered hardware for years, in the form of the Microsoft Mouse, the Microsoft Keyboard, and today with the XBOX, the Kinect, and the Surface. They also offer cloud services and content (music, books, and movies).

Google offers some hardware (the Nexus phones and tablets) but also works with manufacturers. They offer the Chromebook hardware that runs their Chrome browser. They offer cloud services. They have also gotten into the music and video markets, with Google play and YouTube.

Amazon.com offers hardware, but only the the form of the Kindle. They do not offer PCs or phones. They have a rich offering of services with their cloud systems.

Apple offers hardware, software, content, and little in the way of cloud services. Their MacBooks and iPads (and the operating systems) are respected by all. They provide content in the form of music, movies, books, and newspaper subscriptions. Yet their focus is on consumers, not the enterprise. This is clear in their iCloud offerings, which are designed for individuals.

In this light of hardware, software, services, and content, the other "big names" of the tech world are lacking:

Barnes and Noble offers hardware (Nook tablets and e-readers) and the software to run them, but nothing for development or the office. They offer content but not services.

IBM offers hardware and software but not content. They don't sell books or music. They offer cloud services, in addition to their old-school consulting services.

Facebook offers services and content, but not hardware and software. (This is why the rumor of a Facebook phone keeps returning.) Facebook uses cloud computing for their servers but doesn't offer it to customers. They offer other services, such as a platform for games and an authentication service for web site log-ins.

Yahoo offers services and some (limited) content but not hardware or software.

I'm not claiming that a vendor needs all four of these components to be profitable. IBM and Yahoo are doing rather well. (Barnes and Noble not so much, but that is a problem specific to their market.) But the presence (or absence) of these four components is important, and decides how a vendor can assist a client.

The new dimensions of hardware, software, services, and content affect hiring organizations too. Systems will need all of these components (to one degree or another) to satisfy a customer's needs. When looking for solutions from vendors, and when looking to hire, companies will have to weigh the strengths of the vendor (or the candidate) in all of these areas.
The smart, big vendors are offering all services. The smart, small vendors will offer a carefully selected subset and ensure that they can provide quality. The same goes for candidates. The heavyweights will have expertise in all areas, the middleweights light expertise in all and strength in a few, and the lightweights will be capable in one or two.

The task for vendors (and candidates) is to build their skills along these dimensions, and present them to clients.

Mobile/cloud needs a compelling application

There has been a lot of talk about cloud computing (or as I call it, mobile/cloud) but perhaps not so much in the way of understanding. While some people understand what mobile/cloud is, they don't understand how to use it. They don't know how to leverage it. And I think that this is part of the adoption of mobile/cloud, or any new technology.

Let's look back at personal computers, and how they were adopted.

When PCs first appeared, companies did not know what to make of them. Hobbyists and enthusiastic individuals had been tinkering with them for a few years, but companies -- that is, the bureaucratic entity of policies and procedures -- had no specific use for them. An economist might say that there was no demand for them.

Companies used PCs as replacements for typewriters, or as replacements for office word processing systems. They were minor upgrades to existing technologies.

Once business-folk saw Visicalc and Lotus 1-2-3, however, things changed. The spreadsheet enabled people to analyze data and make better decisions. (And without a request to the DP department!) Businesses now viewed PCs as a way to improve productivity. This increased demand, because what business doesn't want to improve productivity?

But it took that first "a-ha" moment, that first insight into the new technology's capabilities. Someone had to invent a compelling application, and then others could think "Oh, that is what they can do!" The compelling application shows off the capabilities of the new technology in terms that the business can understand.

With mobile/cloud technology, we are still in the "what can it do" stage. We have yet to meet the compelling application. Mobile/cloud technology has been profitable for the providers (such as Amazon.com) but not for the users (companies such as banks, pharmaceuticals, and manufacturers). Most 'average' companies (non-technology companies) are still looking at this mobile/cloud thing and asking themselves "how can we leverage it?".

It is a good question to ask. We will keep asking it until someone invents the compelling application.

I don't know the nature of the compelling application for mobile/cloud. It could be a better form of e-mail/calendar software. It might be analysis of internal operations. It could be a new type of customer relationship management system.

I don't know for certain that there will be a compelling application. If there is, then mobile/cloud will "take off", with demand for mobile/cloud apps and conversion of existing apps to mobile/cloud. If there is no compelling application, then mobile/cloud won't necessarily die, but will fade into the background (like virtualization is doing now).

I expect that there will be a compelling application, and that mobile/cloud will be popular. I expect our understanding of mobile/cloud to follow the path of previous new technologies: awareness, understanding, application to business, and finally acceptance as the norm.

Limits to growth

The shift from desktop and web applications to mobile applications entails many changes. There are changes in technology, new services and capabilities, and integration of apps and the sharing of data. Yet one change that has seen little discussion is the limits of an app's size.

Desktop applications could be as large as we wanted (and sometimes were larger than we wanted). It was easy to add a control to a dialog, or even to add a whole new dialog full of controls. A desktop application could start small and grow, and grow, and grow. After a short time, it was large. And after a little more time, it was "an unmanageable monstrosity".

The desktop PC technology supported this kind of growth. Desktop screens were large, and got larger over time. (Both in terms of absolute dimensions and pixel count.) The Windows UI philosophy allowed for (and encouraged) the use of dialogs to present information used less frequently that the information in the main window. Thus, application settings could be tucked away and kept out of sight, and users could go about their business without distractions.

But the world of mobile apps is different. I see three constraints on the size of apps.

First is the screen. Mobile apps must run on devices with smaller screens. Cell phones and tablets have screens that are smaller than desktop PC monitors, in both absolute dimensions and in pixel count. One cannot simply transfer a desktop UI to the mobile world; the screen is too small to display everything.

Second is the philosophy of app UI. Mobile apps show a few key pieces of information; desktop apps present dozens of fields and can use multiple dialogs to show more information. Dialogs and settings, encouraged in desktop applications, are discouraged in mobile apps. One cannot simply port a desktop application to the mobile world; the technique of hiding information is dialogs works poorly.

Third is the turnover in technology. Mobile apps are generally client-server apps with heavy processing on servers and minimal presentation on clients. The mobile app platforms change frequently, with new versions of cell phones and new types of devices (tablets and Windows 8 Metro devices). While there is some upward compatibility within product lines (apps from the iPhone will run on the iPad) there is a fair amount of work to make an app run on multiple platforms (such as porting an app from iPhone to Android or Windows 8). Desktop applications had a long, steady technology set for their UI; mobile apps have a technology set that changes quickly.

This third constraint interests me. The frequent changes in mobile devices and their operating systems means that app developers have incentive to update and revise their applications frequently. Certainly one can write an app for the earliest platforms such as iOS 1.0, but then you lose later functions. And the rise of competing platforms (Android, Windows 8) means new development efforts or you lose those shares of the market.

I expect that technology for mobile devices will continue to evolve at its rapid pace. (As some might say, this rapid pace is "the new normal" for mobile development.)

If mobile devices and operating systems continue to change, then apps will have to change with them. If the changes to devices and operating systems are large (say, voice recognition and gesture detection) then apps will need significant changes.

These kinds of changes will limit the size of a mobile app. One cannot start with a small app and let it grow, and grow, and grow as we did with desktop PC applications. Every so often we have to re-design the app, re-think our basic assumptions, and re-build it. Mobile apps will remain small because will be constantly re-writing them.

 I recognize that I am building a house of cards here, with various assumptions depending on previous assumptions. So I give you fair warning that I may be wrong. But let's follow this line of thinking just a little further.

If mobile apps must remain small (the user interface portion at least), and mobile apps become dominant (not perhaps unreasonable), then any programs that a business uses (word processing, spreadsheets, e-mail, etc.) will have to be small. The world of apps will consist of small UI programs and large server back-ends. (Although I have given little thought to the changes for server technology and applications. But let's assume that they can be large apps in a stable environment.)

If business use the dominant form of computing (mobile apps) and those apps must be small, then business processes must change to use information in small, app-sized chunks. We cannot expect the large, complex data entry applications from the desktop to move to mobile computing, and we cannot expect the business processes that use large, complex data structures to run on mobile devices.

Therefore, business processes must change, to simplify their data needs. They may split data into smaller pieces, with coordinated apps each handling small parts of a larger dataset. Cooperative apps will allow for work to be distributed to multiple workers. Instead of a loan officer that reviews the entire loan, a bank may have several loan analysts performing smaller tasks such as credit history analysis, loan risk, interest rate analysis, and such.

These business changes will shift work from expert-based work to process-based work. Instead of highly trained individuals who know the entire process, a business can use specialists that combine their efforts as needed for each case or business event.

That's quite a change, for a mobile device.