Group items tagged

The question The main question in play here is: How thick should clients be? Let me define my terms: I define the Client as the thing which is used by exactly one user, which interacts directly with that user, and which is probably physically close to that person. I define the Server as the thing which is shared by multiple users, which interacts directly with the Client, and which could be physically located anywhere. I define the Pipe as the connection between the Client and the Server. I define the notion of a Thick client as a relative term. Thicker clients have more app-specific code and are less dependent on the Server. Thinner clients leave more of the app-specific work to be done on the Server. There are two main variables in decisions about the thickness of clients: The quality of the Pipe: This includes bandwidth, latency, availability, reliability, and cost The Client side costs: This includes cost of hardware, software development, deployment, upgrades, and maintenance. And, there are two laws which apply: As the quality of the pipe goes up, the client can get thinner. As the client side costs go down, the client can get thicker.

why does the thickness of Clients vary? Because varying Client thickness creates opportunities to compete in the marketplace. You can differentiate yourself from your competition by making your Client thicker (more expensive) and talking about performance and a better user experience and stuff like that. Or, you can differentiate yourself by making your Client thinner (less expensive) and talking about lower Total Cost of Ownership and easier installation and stuff like that.

This issue is not new Back in the 1960s and 1970s, when we only had mainframes and minicomputers, there was a distinction between smart terminals (thick clients) and dumb terminals (thin clients). In the 1980s, we got workstations (really expensive thick clients, purchased by people who perceived them as cheap compared to the mainframes and minis) and microcomputers (far less expensive thick clients, purchased by people who previously didn't have a computer at all). In the early 1990s, the high cost of workstations gave rise to X terminals, thin client devices which couldn't do much more than display the graphical user interface. My manager bought one of those fancy new 19.2k modems and actually tried doing Motif widget development from home. In the mid 1990s, web browsers appeared. For a very brief time, this technology was regarded only as a way to collaborate on hypertext documents. This phase of the web lasted for most of an afternoon. Meanwhile, back in Champaign, Illinois, the Unsung Hero and His Eminence were busy building a web browser which had more "stuff" in it. What kind of stuff? The sort of stuff that made web browsers into a platform for delivery of apps. And the technologies of the web have been moving primarily in that direction ever since.

The question The main question in play here is: How thick should clients be? Let me define my terms: I define the Client as the thing which is used by exactly one user, which interacts directly with that user, and which is probably physically close to that person. I define the Server as the thing which is shared by multiple users, which interacts directly with the Client, and which could be physically located anywhere. I define the Pipe as the connection between the Client and the Server. I define the notion of a Thick client as a relative term. Thicker clients have more app-specific code and are less dependent on the Server. Thinner clients leave more of the app-specific work to be done on the Server. There are two main variables in decisions about the thickness of clients: The quality of the Pipe: This includes bandwidth, latency, availability, reliability, and cost The Client side costs: This includes cost of hardware, software development, deployment, upgrades, and maintenance. And, there are two laws which apply: As the quality of the pipe goes up, the client can get thinner. As the client side costs go down, the client can get thicker.

This issue is not new Back in the 1960s and 1970s, when we only had mainframes and minicomputers, there was a distinction between smart terminals (thick clients) and dumb terminals (thin clients). In the 1980s, we got workstations (really expensive thick clients, purchased by people who perceived them as cheap compared to the mainframes and minis) and microcomputers (far less expensive thick clients, purchased by people who previously didn't have a computer at all). In the early 1990s, the high cost of workstations gave rise to X terminals, thin client devices which couldn't do much more than display the graphical user interface. My manager bought one of those fancy new 19.2k modems and actually tried doing Motif widget development from home. In the mid 1990s, web browsers appeared. For a very brief time, this technology was regarded only as a way to collaborate on hypertext documents. This phase of the web lasted for most of an afternoon. Meanwhile, back in Champaign, Illinois, the Unsung Hero and His Eminence were busy building a web browser which had more "stuff" in it. What kind of stuff? The sort of stuff that made web browsers into a platform for delivery of apps. And the technologies of the web have been moving primarily in that direction ever since. Java applets (developed a fatal disease called Swing) ActiveX (declared dead seven years after it went missing) Flash (murdered by Steve Jobs) Silverlight (murdered by HTML5) In the late 1990s, people (Oracle, I think?) tried to sell something called a Network Computer. It was a little PC with a video card, some RAM, an ethernet card, a web browser, and no hard disk. Thin.

HTML5 arrived. Actually, the spec is still a long way from being finalized, but nobody knows that. People needed a name, so they started saying "HTML5" before it was fully cooked. Common usage of the term "HTML5" is actually fairly accurate, at least compared to the way telecom companies use the term "4G". And now, this war has moved to the battlefield of mobile. Smartphones and tablets.

Product/market fit means being in a good market with a product that can satisfy that market. You can always feel when product/market fit isn’t happening. The customers aren’t quite getting value out of the product, word of mouth isn’t spreading, usage isn’t growing that fast, press reviews are kind of “blah”, the sales cycle takes too long, and lots of deals never close. And you can always feel product/market fit when it’s happening. The customers are buying the product just as fast as you can make it — or usage is growing just as fast as you can add more servers. Money from customers is piling up in your company checking account.