Edmonton Lean Startup Circle

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.

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.

when it comes to Web­site opti­miza­tion, the three fun­da­men­tal ques­tions pretty much never change: Who is com­ing to the site? How did they arrive? And what are their goals? What’s the next step for­ward for them both in terms of their goals and your con­ver­sion funnel? What do they need to under­stand, believe, and feel in order to con­fi­dently take those next steps

under­stand WHY web vis­i­tors do what they do. Ana­lyt­ics can tell you what vis­i­tors are doing, but you’ll never really fig­ure out WHY they’re doing it until you get a grasp on these questions.

often get asked about finding cofounders and I usually give the standard list of characteristics of what I look for in a founder.  And I emphasize the value of a founding team with complementary skills sets – i.e. the hacker/hustler/designer cofounder archetype for web/mobile apps.

But Jessica Alter, Cofounder & CEO of FounderDating, pointed out that cofounders did not mean two founders in the same room.  She suggested that I was missing one of the key attributes of what makes successful startup teams powerful. She suggested that how cofounders fight was a key metric in predicting the success of a founding team.  

one of the key things to pay attention to in a search for a cofounder is how you fight.

We’ve listed some best practices to help marketers stay compliant with Canada’s new anti-spam law: Be very clear on who is sending the message. A marketer sending a message on behalf of a brand could be responsible. Follow the subscribers rule – get permission (explicit permission) to email your subscribers. If there’s not a request for consent, it’s not consent. Respect and govern the one-to-one marketing relationship that you have with subscribers. Honor each individual’s unique preferences with regard to communication, content, frequency and channel. Provide recipients with an obvious, clear and efficient email or web-based means to opt-out of receiving any further business and/or marketing email messages from your organization. Keep records of the type of consent obtained from recipients so that email lists can be scrubbed prior to campaign broadcasts. Include a link to your company’s privacy policy in every email. The privacy policy should explain the intended use and disclosure of any personal information that might be gathered through “clickstream” means or other website monitoring techniques. Take reasonable steps to ensure that the addresses on your email lists were obtained with proper consent.

For more information on the legislation, visit the Government of Canada’s Anti-Spam Legislation website at: www.fightspam.gc.ca.

Regardless of the law, explicit permission is the best practice and produces the top results and deliverability.

Size of call to action button versus less important call to actions A web page may have multiple calls for action. To indicate the relative importance of a call to action with respect to other actions, you can vary their sizes. Here is an example of this concept on the paramore|redd 3 website where the call to action button that asks the user to sign up for their newsletter is significantly larger than the continue reading call to action, indicating that on this web page, they would rather you take the action of subscribing versus reading the blog posts.