Why Are Smartwatches Focusing on Notifications?

It is very interesting to see the new smartwatches focusing on notifications as their main feature. This begs the question; why are notifications so important?

Are notifications so important that many people are willing to purchase a several hundred dollar device and wear it wherever they go?

I don’t think so. I think that the only reason why smartwatches are offering notifications is because it was relatively easy to do. Smartwatches are small so you can’t display a lot of information on them. You can’t provide a good UI that can be used to enter information. The only use-case that was left was notifications. The focus on notifications was not because notifications are important; it was because there was nothing else that Samsung, Google could think of putting on the device.

So the issue remains. Smartwatches are a form-factor in search of a use-case. This is not innovation.

Innovation in wearables lies in understanding what problem they can uniquely solve. How can a device that will be with you at all times enrich your life?

Of course, there may not be a market for wearables after all. Unlike smartphones, wearables are not a replacement for a device that people were already carrying around with them. Wearables are asking the public to carry a second device in addition to their smartphone, which overlaps a lot in functionality. Whether or not there is a market for such a device is very unclear. Even if it existed, it is easy to imagine that it would take a huge amount of time to spread. It is a speculative market.

Innovation is rarely about a technology searching for a market. It’s more often about making a complex product simpler and easier to use, thereby both increasing the number of people who use it and the occasions in which it is used. Notifications simply don’t qualify for this.

Why the Fallacy of Android-First

Dave Feldman wrote a very interesting post on TechCruch (“The Fallacy of Android-First”) where he details why the startup that he founded (Emu) launched Android-first, but after sixteen months, they reverted to iOS only.

There are many interesting points in this post. Here, I would like to categorize his findings and to draw a typical general picture of an innovative market leader and a follower frantically trying to catch up.

The allure of Android

Followers generally try to catch up with the combination of a) price and b) more features. With both more features and a price benefit, it seemly looks like the follower’s offering is better in all accounts. However, if you look under the hood, you often find that the features haven’t been well thought out and that they are actually quite useless.

In comparison, leaders usually focus on actual benefits. If they succeed, the leaders prevail and the market separates into low-end which becomes a price war, and the high-end which is rather stable. If leaders fail and are dragged into the price war, then the market loses the leader and everybody chases features that look good on paper, but are not beneficial to the user.

This is a common theme in many markets. It is also what is happening in mobile.

The Dave’s article, he mentions the allure of Android as the following;

  1. On Android, you can replace the built-in Messages app, while still using the underlying SMS/MMS medium, saving the effort of building a communication service.
  2. Android apps were supposedly easier to build.
  3. Fragmentation was supposedly becoming less of an issue.

The reality

The reality was that allure #1 was a feature that was not well implemented. It was so bad that it was close to unusable from a developer point of view.

  1. Android’s SMS APIs are not well documented. The APIs have also changed over time.
  2. Individual apps can block each other from receiving SMSes. This means that the presence of other apps affects whether your app works or not.
  3. Other issues with MMS make it a nightmare to support.

So the feature was there on Android, but it was very difficult to use in the real world.

There are also other issues described in the post and they basically say the same thing; Android has the features and support, but it’s often not very useful.

The lesson

The lesson is that features which the followers implement are rarely useful. You can’t trust them to have thought out all the issues. Although leaders will also fail sometimes, followers are much more likely to introduce useless features.

How are Apps Dominating Mobile Usage?

On April 1st, 2014, analytics firm Flurry released a report on how time is spent on mobile devices.

NewImage

This data is interesting for a number of reasons;

  1. Apps are dominating the mobile usage. As of 2014, Internet browsers are used for only 14% of the time. 86% of the time, mobile users are using apps.
  2. App dominance is increasing. In 2013, Internet browsers were used for 20% of the time compared to 14% in 2014.
  3. Facebook and other social activities constitute 28% of usage time. This compares to 32% for gaming.
  4. Other usages are fragmented with 4% for YouTube (watching video), 4% for productivity, 3% for news.

What does this all mean? Here are a few thoughts of mine.

Why did apps dominate mobile usage?

Both mobile apps and the mobile web have their pros and cons. Although it’s easy to point out the advantages that apps have and to attribute success to these, we have to remember that a lot of people predicted that HTML5 would ultimately win. There are arguments for both sides and hence it’s very difficult to understand what the ultimate driver of success was.

Why is this important? Why do we have to analyze what has already happened?

I have a sense that the success of apps on mobile might affect how we use desktop computers. It is not entirely unthinkable that we might see a resurgence of apps on the desktop. By analyzing how apps dominated mobile usage, we might gain insight on whether this is truly likely.

How can Microsoft fix the ecosystem gap

The smartphone market is dominated by Android and iPhone and it is increasing difficult for new entrants to gain a foothold in the market. Windows Phone is reported to be gaining market share in the low-end, but we want to know whether it can possibly grow to be a significant player.

The problem is the ecosystem. Android and iPhone both have a large number of apps and services. Windows Phone lags in this regard and this is considered the reason why it doesn’t stand a chance.

Let’s look at this by category. Looking a social networks, the big ones are cross platform. Facebook, WhatsApp, LINE, Instagram, Pinterest and many others have native apps for Windows phone. Windows Phone no longer lags here.

In games, Windows Phone lags a lot. Popular games like Puzzle & Dragons and Candy Crush Saga are not yet available.

In the other categories, it is possible that Windows Phone still is vastly inferior in the number of apps available. However, this probably is not very much of an issue. They aren’t an vital part of the smartphone experience.

If Microsoft can convince major game developers to create Windows Phone versions, then it can mostly fix the platform gap.

Usage itself is different from desktops

Although I don’t have data available for desktop computers, I imagine that it would be very different from Flurry’s data. Instead of games, we would see a lot of productivity apps (mostly MS-Office) being used. Email applications would also be huge.

It’s not a simple case of apps replacing the web. It’s that these devices are fulfilling a different purpose. Hence there is no guarantee that companies with a big presence on the desktop web will ultimately succeed on mobile.

For example, Gmail has a large presence on the desktop web and is also included in Android as a part of Google Play. It maintains a large market share of email on mobile devices. It doesn’t really matter though because the preferred messaging tool on mobile is not email. Instead, the social messaging platforms dominate.

Likewise, Google maintains a large market share for mobile web search. It doesn’t matter because people don’t do web search on their mobile devices.

Will Google Use Humans to Fix Google Now?

I have never used Google Now, but I was always skeptical. The use cases that were being reported on the web always were extremely limited, and it seemed that they were simply telling us about the things that worked but not about the things that didn’t.

A couple of days ago, Janko Roettgers wrote on GigaOM about how Google Now actually fails, even in the limited tasks it’s supposed to be good at.

We often assume that because Google is collecting huge amounts of information about their users, they are able to understand a lot about who we are and what we want to do. Yes, Google does know where you live and it knows exactly what keywords you used on your searches yesterday. It knows exactly where you are right now. This is all very creepy, especially if you are an Android user. The problem is, there is no guarantee that this information will let Google know your current intentions with any accuracy.

Google has been described as a “decade-old machine learning project”. There are two products from Google which have shown how this can actually be turned into something useful. They are Google AdSense and Google Maps.

Google search basically selects the ads (AdWords) to be displayed based on the keywords that were entered in the search field. Although the information that Google holds about the user is also used to tweak the results, this is not the main driver of the AdWord ads to be displayed. With AdWords, the user has directly expressed their intent through the search keywords and Google does not try to second-guess it. This intent is what drives the ads and this is why I don’t include it in the current discussion.

AdSense is more “intelligent” than AdWords because it tries to guess user intent. It analyses the content of the page the user currently is browsing. It uses knowledge of what pages the user has visited recently. It uses location data. It combines all of these to determine which ad the user is most likely to click on. In reality, AdSense fails most of the time. It does not correctly estimate the user’s current intent. But that’s OK. The click-through rate (CTR) of AdSense is at most a few percent and the vast majority of people aren’t interested in what is shown in an online ad. It’s completely acceptable for AdSense to get it wrong most of the time. Therefore, the “intelligent” guesses of AdSense are successful even if they are completely wrong most of the time. AdSense will still be immensely successful when the majority of users are pissed-off by the ads. It only takes a small percentage of correct answers to succeed.

Google Maps is a totally different kind of “intelligence”. Google Maps has to be accurate for the vast majority of the time. It has to be something like 99.999% accurate or more. Otherwise, we would constantly get reports that some poor drivers drove themselves into a desert. How can Google Maps be so accurate when AsSense is so sloppy? The secret lies in humans. To quote an article by Alexis Madrigal on The Atlantic.

I came away convinced that the geographic data Google has assembled is not likely to be matched by any other company. The secret to this success isn’t, as you might expect, Google’s facility with data, but rather its willingness to commit humans to combining and cleaning data about the physical world. Google’s map offerings build in the human intelligence on the front end, and that’s what allows its computers to tell you the best route from San Francisco to Boston.

Even though Google gets vast amounts of information from satellites and street-view cars, it has to combine these with an army of human beings to gain accuracy. Without these human beings, they cannot get the error rate to an acceptable level. The kind of “intelligence” in Google Maps can only be attained with a huge number of people who manually curate the information.

Now let’s get back to Google Now. Which kind of “intelligence” do we need? Do we want a personal assistant that thinks it is acceptable to guess correctly only a few percent of the time? Or do we want a personal assistant that truly knows what we want to do next?

If we want the latter, we may have to be content with an army of human beings plowing through your most personal information, helping Google’s not-so-accurate machine learning algorithms to make sense of your daily routines.

パソコンのブランドイメージ

私はもっぱらMacを使っていますが、たまにWindowsを使わなければならないこともあるので、昨日Windowsパソコンを買いに行きました(オフィスにあるのは2003年発売モデルでさすがにきつくなってきましたので)。

数多くのメーカーが並んでいる中で、結局は中古のThinkPadを購入しました。実はこのとき、自分の中でブランドイメージをかなり強く意識しました。そこで、現時点で自分がパソコンブランドに対して持っているイメージを記録する意味で、ここに書きとどめようと思います。

日本メーカーのブランドイメージ

  1. 世界で戦えていない
  2. 高い
  3. 今後、何年続く変わらない。もう既に店じまいしている(NECやSony VAIO)

この中で例外なのは世界で戦ってきたToshibaのDynabook。そして軽くて頑丈なPanasonicのLet’s Note。

ただ”Let’s Note”というブランド名は、製品の質実剛健さとは裏腹に、英語にするとあまりにも軽いイメージで、恥ずかしくて外国に持って行けないという感覚があります。

アジアメーカー

  1. 性能の割には安い
  2. もしかしてボロいかも知れない

「ボロいかも知れない」というのはアジアメーカーに限ったことではなく、価格戦争に巻き込まれているすべてのウィンドウズOEMに言えることではあるのですが、アジアメーカーだとより強い不安があります。

特にSofmapに置いてあったASUSの展示機は、トラックパッドがなんだか浮いている感じだったのでかなり不安を覚えました。

USメーカー

DELLとかHPとか。

  1. 外資系の本社支給だから使っているのでしょう?
  2. 安く作るためにアジアに丸投げしているんでしょう?
  3. 本当はパソコンを売りたくないんでしょう?(HPとか)

そしてThinkPad

こうしてみると、ウィンドウズ機の中でブランド的に良いイメージのものって全然無いのがわかります。その唯一に例外とも言えるのがThinkPadではないでしょうか?

  1. 日本で生まれた製品!
  2. 伝説的なキーボードへのこだわりに見られるように、スペック以外にもこだわっているという安心感

そういうこともあって、中古でCore i5搭載のT410sを中古で購入しました。かなり使い減らされていて、ガタが来ていましたが、それでも下手に新品のASUSを買うより長持ちするんじゃないかと思わせるところがThinkPadにはあります。

私にとって、ブランドというのは「目に見えないところ、スペック以外のところにも注意を払っているよ」という暗黙の約束です。だからブランドというのは、購入後にじわじわと良さが伝わってきます。そして「やっぱりこのブランドを買って良かった」と思えるのです。

安物ブランドは買った後に後悔します。そして「まぁ安かったからしょうがないよね」と自分に言い聞かせることになるのです。

この差は大きいと思うのですが。

Internet Explorer 8, 9 usage decline is quite slow

With the support for Windows XP ending in three weeks, we as web developers would hope that usage of Internet Explorer (the newest version of IE to run on Windows XP) to rapidly approach zero.

Support for Windows XP is ending

Unfortunately, this doesn’t seem to be the case. Looking at statistics from StatCounter, it appears that IE8 usage is still 7-8% in the USA and Japan. Encouragingly, the pace of usage decline seems to be accelerating and we might reach almost zero within the year 2015.

StatCounter browser version partially combined US monthly 201302 201402

StatCounter browser version partially combined JP monthly 201302 201402

What is more troublesome is IE9 data. IE9 usage is declining and is already quite low at 5-7%. However the pace of usage decline is quite slow and it looks like it will be with us at least as long as IE8. This is probably due to corporations blocking automatic updating of Internet Explorer.

Analyzing StatCounter data at per-day resolution, we can see that before IE10 debuted, IE9 was used a lot during weekends. However, after IE10 was introduced and most of the consumer users shifted to IE10, corporate users remained on IE9. As a result, IE9 usage became more pronounced during week days.

StatCounter browser version partially combined US daily 20120201 20140231

StatCounter browser version partially combined JP daily 20120201 20140231

In summary, despite Windows XP not being supported after April this year, it looks like IE8 will still be with us, at least till the end of this year. IE9 also looks quite stubborn and since it’s on Windows Vista and 7, it’s unlikely that we will see it go away. We web developers will still have to support these legacy browsers for another year.

日本人のiPhone好きは特殊か、それとも普通か?

なぜ日本人はiPhoneが好きか?

2014年1月15日にカンター・ジャパンが日本のiPhoneのシェアが69.1%で、Androidの30%を圧倒していることが紹介されました。そしてどうして日本人はこんなにもiPhoneが好きなのかということがネット上で話題になりました(例えばJ-Cast「日本人はなぜこんなにiPhoneが好きなのか ユーザのITリテラシーが低いから?」)。

理由ははっきりしていました。それは日本ではiPhoneの価格を補填していて、Android端末と価格差がなかったからです。場合によってはiPhoneの方がAndroidを買うよりも割安という状態でした。

「同じ価格なら、大多数の人はiPhoneを買うでしょう?」

というわけです。

もちろん他の要因を考えることはできます。理屈としてはかなり無理がありますが、例えば上記のJ-Castの記事では以下のような要因も挙げられています。

角川アスキー総合研究所主席研究員の遠藤諭氏に聞くと、考えられる要因を挙げた。まず、欧米と比べて日本のユーザーはITリテラシーが低いとの指摘だ。欧米の学校におけるIT教育の素地は、日本とは比べ物にならないという。そのため、スマホ入門者にとっては比較的操作がしやすいiPhoneに流れるのではないか、と推測した。

まぁ、どう考えてもこじつけとしか言えない、とんでもない理屈ではあります。

他にもいろいろなことが言われていますが、同程度に穴だらけの理屈がまかり通っています。

実は中国人も日本人と同程度にiPhoneが好き

つい先日、Umengという中国に強みのあるアプリ・アナリティックス企業がスマートフォンやタブレットの利用動向のレポートを出しました。その中でこう述べています。

High-end smart phones (pricing above 500US$) have a significant market share in China, contributing 27% of total devices.

… 80% of these are iPhone.

つまり500 US$よりも高価なスマートフォンを購入できるだけの豊かな中国人の間では、80%の人がiPhoneを購入しています。一言で言うと

「買うことさえできれば、大多数の人はiPhoneを買うでしょう?」

というわけです。

日本ではiPhoneが実質0円なので、「買うことさえできれば」というのはスマートフォンユーザの全員が満たしている基準になります。

ということで日本のiPhoneのシェア 69.1%と、中国のハイエンド・スマートフォン・ユーザのシェア80%というのは同じものを見ていると言えます。

結論として中国でも日本でも、

「買うことさえできれば、7-8割の人はiPhoneを買う」

と結論できます。

なかなかデータは手に入りませんが、日本と中国に見られるこの数字はおそらく世界の大多数の国でも同じだろうと私は推測しています。つまり日本人のiPhone好きは特殊な現象はなく、ましてやガラパゴスでもなく、普遍的なことだと思います。

The OS for Wearble Devices (Android Not)

Google is releasing an Android SDK for wearables this month (March, 2015).

So what is their vision for wearables is? The example that Pichai reportedly gave is a “smart jacket” with sensors.

Seriously?

The only wearables that I know of that are currently succeeding in the mass market, are the fitness trackers. The Nike FuelBand’s and the Jawbones. NPD has reported that the market for digital fitness devices was $330 million. Given the price of these devices, it looks like millions have been sold.

So the question is, does the FuelBand run Android? Does it run Linux?

The answer lies in the hardware that enables them to be small enough to comfortably fit on your wrist and last a full day on a single battery charge. It looks like the CPU is an ultra-low power ARM Cortex-M3 with 256 Kbytes flash (hacknikefuelband.com).

Not really enough to run Linux or Android.

Even the Pebble smartwatch which is a bluetooth connected notification center, uses a non-Linux OS (FreeRTOS) according to Wikipedia.

Simply put, the hardware that would comfortably fit on your wrist cannot run Android yet. Pichai is right; you need something jacket-sized.

64-bit Android

In September, 2013, just after the iPhone 5s was announced, I wrote that we would be able to gauge Google’s commitment to the high-end based on when the 64-bit version of Android would be released. I commented that Google might not prioritize 64-bit, mainly because their focus has shifted to the low-end with the departure of Andy Rubin.

Until now, I had not heard any credible reports on when a 64-bit version of Android would be available. Now, on March 11th, ABI Research reports that “the first 64-bit version of Android OS is expected in the second half of the year”.

At this point, there is no way of knowing how accurate ABI Research’s prediction is. There is also no way of knowing if Android and ARM’s 64-bit implementation will deliver a significant performance improvement like Apple’s A7 chip did, or whether the gain will be rather insignificant as most industry pundits claimed when the A7 was announced.

All I can say is that we don’t know yet.

Writing No-Framework ASP.NET (part 3: reusing code)

In my previous two articles describing my writing a no-framework ASP.NET file, I described how ASP.NET handles encoding and how a .aspx file should be structured.

In my third article, I will discuss how we can make code reuseable.

Making code reusable in classic ASP, PHP, etc.

Here, I will use the example that I showed in my second article and discuss how we could reuse the link method.

In PHP, you reuse code by placing it in a separate file and using the import method to include it into all the files where you want to use it.

import('file<em>that</em>defines<em>the</em>link_method.php');

You can use this (and variants like require) to reuse libraries, or reuse HTML fragments (i.e. common headers and footers of the pages in the website).

In classic ASP, you use the include syntax to the same effect.

<!--#include file="file_that_defines_the_link_method.asp"-->

ASP.NET is different. There isn’t a single method to reuse code but instead there are several ways that each have its own intended use-cases. Coming from a PHP background, it was quite confusing; I didn’t know which method I should be using. This article give you a good idea of the options that you have.

The important thing is that ASP.NET makes the distinction between what kind of code you intend to reuse. If you are going to reuse libraries which contains functions, then you should put them in App_Code. On the other hand, if you want to reuse HTML fragments, then you should use user controls.

Reusing functions

The App_Code must be created at the root of you web site. All files in this directory or any subdirectories that have the extension .vb or .cs will be treated as Virtual Basic or C# files respectively.

The code in App_Code will be available in every ASP.NET file that is in this application. Hence this is the ideal location to store libraries. In our case, it’s a good place to define the link function.

The downside to AppCode is that the files are pure Visual Basic or C#. This means that if you can’t simply write HTML code in the files. You have to generate them as strings (and there is no HEREDOC syntax in Visual Basic either). Hence, the AppCode folder are not a good place to put “partials”; large fragments of reusable HTML code.

For our example, we create the following link.vb file in the App_Code directory.

Imports Microsoft.VisualBasic
Imports System.Net
Imports System.IO</p>

<p>Private Function urlEncodeUtf8(myString As String) As String
  urlEncodeUtf8 = HttpUtility.UrlEncode(myString, new System.Text.UTF8Encoding)
End Function</p>

<p>Public Function link(label As String, endpoint As String, query As String(,)) as String
  Dim tuples As New ArrayList()
  Dim i As Integer
  For i = LBound(query) To UBound(query)
    tuples.Add(query(i, 0) &amp; "=" &amp; urlEncodeUtf8(query(i, 1)))
  Next
  Dim href As String = "http://api.example.com/api.php?ep=" &amp; endpoint &amp; "&amp;" &amp; Join(tuples.ToArray(), "&amp;")
  link = "<a href=""" &amp; href &amp; """>" &amp; label + "</a>"
End Function

Then then we simply use the link function as we did in our previous article.

<%= link("Bovine(ウシ)", "endpoint.php", _
                             New String(,) {{"type", "Whole IgG"}, _
                                            {"reactivity", "Bovine(ウシ)"}, _
                                            {"title", "Bovine Whole IgG secondary-antibodies"}}) %>

Reusing HTML fragments

Another way to reuse code in ASP.NET is User Controls. Instead of putting link function in the App_Code directory, let’s see how we use reuse it with User Controls.

To implement the link function using User Controls, we would create the following control link.ascx file and place it in a “Controls” directory that we create at the root of the web site. Unlike the “AppCode” directory which always has to be at the root-level of the web site and named exactly “AppCode”, the location and name of the “Controls” directory is arbitrary because we specify the file path whenever we use our controls.

' code for "~Controls\link.ascs"
'
<%@Import namespace="System.Net" %>
<%@Import namespace="System.IO" %>
<%@ Control Language="VB" ClassName="Link" %></p>

<script runat="server">
  Public label As String
  Public endpoint As String
  Public query As String(,)
  Protected href As String

  Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs)
    link(label, endpoint, query)
  End Sub

  Private Function urlEncodeUtf8(myString As String) As String
    urlEncodeUtf8 = HttpUtility.UrlEncode(myString, new System.Text.UTF8Encoding)
  End Function

  Public Sub link(label As String, endpoint As String, query As String(,)) as String
    Dim tuples As New ArrayList()
    Dim i As Integer
    For i = LBound(query) To UBound(query)
      tuples.Add(query(i, 0) & "=" & urlEncodeUtf8(query(i, 1)))
    Next
    href = "http://api.example.com/api.php?ep=" & endpoint & "&" & Join(tuples.ToArray(), "&")
  End Function
</script>

<p><a href="<%= href %>"><%= label %></a>

Then, to use this control in a page, we would do the following;

'...
<@ Register TagPrefix="uc" TagName="link" src="~\Controls\link.ascx" %>
'...
<uc:link id="link_1" label="Bovine(ウシ)" endpoint="antibody_reactivity_type.php" />
<% link_1.query = {{"type": "Whole IgG"}, {"reactivity", "Bovine(ウシ)"}, {"title", "Bovine Whole IgG secondary-antibodies"}} %>

The src attribute of the Register directive declares where the source code for the user control exists (“~\Controls\link.ascx” where “~” indicates the root level of the web site). TagPrefix and TagName are used to define the name of the tag we will use for this control. This tag indicates where the user control will be inserted.

The is where the link is going to be inserted in the resulting HTML. You can see that we are providing the label and the endpoint values using attributes. Notice that in label and endpoint are defined as public accessible attributes in the link.ascs user control.

Ideally, we would like to send value for the query attribute to the user control in the same manner. However, it is not possible to send complex values as attributes. You have to do this programmatically on the user control object which is available as the link_1 variable (specified in the id attribute of the tag). That’s why we set the value of link_1.query on a separate line and not inside the tag.

This code example illustrates the strengths and the weaknesses of user controls. User controls are good if you have a lot of HTML that you want to output because you can simply write down the HTML in the .ascx file. They are also good if the values that you want to pass in are simple. Hence they are ideal for header and footer fragments on your web page.

On the other hand, our example simply the weaknesses of user controls. The link example outputs only a short fragment of HTML, so the strengths of User Controls are not being used. On the other hand, passing in complex values is cumbersome, so User Controls are not a good idea if you need to do a lot of this.

If your intention was to reuse large fragments of HTML, user controls would definitely be the way to go.

Summary of the whole project

In my series “Writing No-Framework ASP.NET”, I wrote about my experience in writing simple ASP.NET code to add a few features to otherwise static HTML files.

Coming from a PHP background, these were the things to look out for;

  1. ASP.NET will do charset encoding and decoding in the background. Make sure that it doesn’t meddle with your encodings in a way that you don’t expect it to.
  2. ASP.NET forces you to put different parts of your code in different places. Know where you should put your function definitions and your string output statements.
  3. Passing complex arguments to functions in a terse way is not common in most code examples that you can find. Compared to PHP, Ruby, etc., it can be downright ugly. It is possible to make it acceptable though.
  4. There are different ways to reuse code based on whether you want to share libraries or whether you want to share HTML fragments. This can be confusing.

In closing, I would like to review an occasion where this No-Framework approach would be necessary. A typical case would be the following;

  1. The original website is build with static HTML and is hosted on IIS.
  2. The IIS server is run with default settings by a cautious administrator. The most we can do is persuade him to activate ASP.NET or ASP. We cannot persuade him to install non-Microsoft extensions like PHP.
  3. We only need to add some simple code to pre-existing static HTML pages to make them easier to manage, or to pull-in some content from an API.
  4. After setting the code up, the web-designer will edit the file more frequently than you do, using an editor that is completely out of your control. The encoding of the file and the encoding of the output is their decision, not the programmers.
  5. Maybe we need some simple single-page stuff like contact forms.
  6. You, the programmer, mostly spend your time in PHP, Ruby, Python and other cool web languages. You’re worried that even if you managed to learn enough ASP.NET to use webform postbacks, you’ll forget how to do it in half-a-year. You don’t want to use postbacks. You want to write code that resembles PHP code.

I’m sure that this is quite a common situation but I couldn’t find web sites that guided me through the steps. I hope that this series will help others in a similar situation.