Looking back at the history of HTML and its emerging trends can get quite messy.
I love the idea of HTML 5 and developing some really cool web apps but all those new elements and the varying support have lead me to do a sanity check on all the HTML tags I have at my disposal. And I doubt it's going to settle down any time soon. But I guess that's same story as usual.
In HTML, there is the standard, there are the recommendations, and then there is reality. And at the end of the day, its what works that counts, regardless of whether it is offically approved or not.
Besides adding many new elements, HTML 5 has dropped a few older tags traditionally used for styling. This is a good thing but not nearly enough of the old tags have been dropped for my liking.
For example, why is <big> dropped but not <small>?
Remeber when <tt> was recommended over <code> and <samp> for mono-spaced font? Well <tt> has been dropped but <code> and <samp> are still there? I agree, the only time we see a teletype machine these days is on old movies, but I still fail to see why a browser, regardless of device type or screen resolution is going to show source code in different way to any other browser.
Remember in HTML 3.2 where <strike> was recommended over <s>, the later having been pretty well dropped. Well now <strike> is out and <s>, which came back in with HTML 4 is the winner. <s> probably achieved this by developing an alternate semantic purpose. Rather than meaning strikethrough, <s> is now supposed to mean "Somethings not right with this text". It's still strikethrough at the end of the day though.
And if <s> can change to mean "incorrect" why can't <b> take on the meaning of <strong> and <i> the meaning of <em>?
<b> and <i> are still there but are still strongly discouraged. The argument for this goes like this:
<b> as bold, is a direction of style, not meaning. <strong> on the other hand means to stand out. Some browsers may choose to make the text stand out in way different to bold. In cases where you really want bold, you should use CSS.
But in reality, every browser just bolds the content of <strong> and <strong> has taken on the meaning of bold. Just look at any HTML editor and press the [Bold] button. You will note that they almost always achieve the bold by using the <strong> tag, and not by CSS or <b>, even though in this case, the latter is more correct as per the user's intention.
Same thing for <em> and italic too.
And now of course we have <mark> as in marked with a yellow high-lighter.
My problem is that <strong>, <em> and <mark> all have the same meaning, to make the text stand out. In reality, when your deciding which to use, you end up asking yourself do I want the text bolded, italic or marked in yellow, which is a styling intent, so should be done with CSS anyway.
Any why was <acronym> dropped in favour of <abbr>? A coin flip? Less characters to type? I can't think of any other reason to favour one over the other. Do screen readers spell abbreviations out loud but attempt to read acronyms as words?
(Wow, I'm starting a lot of sentences with And here. My english teacher would turn in her grave.)
There are also a few new tags which I'm not sure I value much. <output> and <time> for example, that as far as I can tell just render as normal output. There is an expectation that they might be rendered a different way in the future. Well I have an expectation that once people get used to them rendering as normal, changing that later is probably not going to happen.
And finally, why can't we come up with one universal format for audio and video. There are three formats for each and not one of the six is supported by all the major browsers. It is a classic case where commercial interest and pride win over common sense. And because we lost this battle now, it's going to be a long time before we ever get to fight it again.
Wednesday, January 30, 2013
Tuesday, January 29, 2013
<textarea> and Turning Wrap Off
A <textarea> control includes a "wrap" attribute, the official values of which are:
The problem for me is that none of these "official" methods actually do the following:
- turn the auto-wrapping feature off so each "paragraph" appears on one line AND
- allow the user to enter a new line by pressing return
In my case I just wanted the user to enter a list of short items, one item per line, but allow for the chance that one of the items might be longer than the width of the control.
IE9 recognises the "white-space" and you can use this to stop wrapping but none of the values allow the user to also hit enter.
FireFox 18 simply ignores the white-space property with respect to user input in a text area.
Actually, I think the white-space property was meant for the actual content that appears in the HTML source, not for user input.
Thankfully, all the major browsers support the "unofficial" HTML "wrap" attribute value of "off". This does exactly what I want except for some reason IE renders in both the scroll bars disabled until overflow occurs in which case it enables the relevant scroll bar. This is both distracting and eats up real estate in smaller text areas. You can solve this with the CSS "overflow:auto". So:
<textarea cols="20" rows="10" wrap="off" style="overflow:auto"></textarea>
- "soft" which is the default behaviour
- "hard" which inserts a line break into the actual content
The problem for me is that none of these "official" methods actually do the following:
- turn the auto-wrapping feature off so each "paragraph" appears on one line AND
- allow the user to enter a new line by pressing return
In my case I just wanted the user to enter a list of short items, one item per line, but allow for the chance that one of the items might be longer than the width of the control.
IE9 recognises the "white-space" and you can use this to stop wrapping but none of the values allow the user to also hit enter.
FireFox 18 simply ignores the white-space property with respect to user input in a text area.
Actually, I think the white-space property was meant for the actual content that appears in the HTML source, not for user input.
Thankfully, all the major browsers support the "unofficial" HTML "wrap" attribute value of "off". This does exactly what I want except for some reason IE renders in both the scroll bars disabled until overflow occurs in which case it enables the relevant scroll bar. This is both distracting and eats up real estate in smaller text areas. You can solve this with the CSS "overflow:auto". So:
<textarea cols="20" rows="10" wrap="off" style="overflow:auto"></textarea>
FireFox prefill and autocomplete="off"
FireFox has the ability to record every value you enter into fields on web pages, and if you visit that page again, it will prefill those fields with the last known value when you refresh a page, go back or revisit that page.
I suppose this is useful for the everyday user but this behaviour is on by default and it overrides when a web developer explicitly states what they want the initial state of the fields to be. This includes things like the "value" attribute of a text field, the "checked" attribute of a checkbox or radio button, the "selected" attribute of an option, and specific content in a text area. Thankfully they seem to draw the line a prefilling a password field.
The behaviour may also if client script events don't take this behaviour into account.
So if you want to to be able to set the initial state of your controls, or you want to ensure that your fields start in their default state such as an empty text field, then you will need to add autocomplete="off" to your controls to tell FireFox to leave them alone.
This works even though "autocomplete" to me means something completely different, but I guess W3 though that adding another attribute prefill="off" or firefoxleavethisdammfieldalone="true" would be overkill.
Another option is to have a little bit of client script that presets the fields and then enable client side events after that. This option might be more useful in an ajax driven page.
I suppose this is useful for the everyday user but this behaviour is on by default and it overrides when a web developer explicitly states what they want the initial state of the fields to be. This includes things like the "value" attribute of a text field, the "checked" attribute of a checkbox or radio button, the "selected" attribute of an option, and specific content in a text area. Thankfully they seem to draw the line a prefilling a password field.
The behaviour may also if client script events don't take this behaviour into account.
So if you want to to be able to set the initial state of your controls, or you want to ensure that your fields start in their default state such as an empty text field, then you will need to add autocomplete="off" to your controls to tell FireFox to leave them alone.
This works even though "autocomplete" to me means something completely different, but I guess W3 though that adding another attribute prefill="off" or firefoxleavethisdammfieldalone="true" would be overkill.
Another option is to have a little bit of client script that presets the fields and then enable client side events after that. This option might be more useful in an ajax driven page.
display:none and jQuery.hide() not working for <option> in IE
For some reason IE (at least IE9) will not allow you to hide an <option> tag. I initially discovered this when when a jQuery.hide() failed in IE but worked in another browser. I created a quick test that included an <option> with a style set to display:none (the equivalent of a jQuery.hide() ) and got the same issue.
I recalled IE had added a whole bunch of HTML attributes in the past and tried a few desperate alternatives like visible="false" or hidden="true" but nothing works at an <option> specific level.
A quick search on the net confirmed this was a known issue. The general recommendation is to remove and re-add the <option> as required.
Another option is to add the HTML attribute disabled to the <option> using jQuery.prop( "disabled", true). This greys out the option and makes it unselectable. This doesn't have the same visual affect but serves a similar purpose.
Never the less it would be nice if IE could add this to their fix list.
IE's <select> has also been a bit of a pain in the past, always rendering on top of content regardless of its position in the HTML or the z-index values.
I recalled IE had added a whole bunch of HTML attributes in the past and tried a few desperate alternatives like visible="false" or hidden="true" but nothing works at an <option> specific level.
A quick search on the net confirmed this was a known issue. The general recommendation is to remove and re-add the <option> as required.
Another option is to add the HTML attribute disabled to the <option> using jQuery.prop( "disabled", true). This greys out the option and makes it unselectable. This doesn't have the same visual affect but serves a similar purpose.
Never the less it would be nice if IE could add this to their fix list.
IE's <select> has also been a bit of a pain in the past, always rendering on top of content regardless of its position in the HTML or the z-index values.
Wednesday, January 16, 2013
The Curly Question of Braces
Sometimes arguments come down to what I call the "Chocolate vs. Caramel" factor.
If I was to ask which of these flavours you preferred most people I'm hoping would not be expecting everyone to answer the same. Nor would I expect them to accuse anyone who answers this question differently as being wrong.
Strangely enough, if I was to replace these flavours with the question of whether the opening curly brace should appear on the same line or the next line, then a lot of people seem to loose this concept of "personal preference" and break out into jihad or something.
The use of braces, curly braces or curly brackets if you prefer (I call them squigglies) actually dates back to before c. The language BCPL (1966) used $( and )$ to delimit a statement block to distinguish them from ( ) used in an expression. This influenced Ken Thomposon when he developed his language B (1969) that actually used { } and was the predecessor to C (1973).
C of course is the language we remember and is still widely in use today. So languages that use squiggly brackets are often described as C-style languages and include C++, Java, C#, Objective-C, JavaScript, PHP and Perl. That's a big chunk of the most commonly used languages in use today.
The issue boils down to whether you should write code like this (same-line):
if ( expr) {
... statements ...
}
or this (next-line):
if ( expr)
{
... statements ...
}
or more importantly, does it even matter?
There are a number of variants on top of this, one that I've encountered in a C++ codebase I had to work on that followed this 'philosophy':
If a single statement:
statement;
can be interchanged with a block of statements:
{
statement1;
statement2;
}
then surely the logical block idention for:
if ( expr)
statement;
should be:
if ( expr)
{
statement1;
statement2;
}
This particular indention isn't widely used and I've only encountered it in the one software house, but as an argument goes it's as valid as most others I've heard.
There are a few cases where there might clearly be a right or wrong answer and they mainly falls into 2 categories, conformance and language peculiarities.
For conformance, the most likely reason is the old "All our code is this way so this is the way we want you to do it". And this is a pretty valid reason. There is lot to be gained from uniformity in large code bases and most developers can make this sort of shift if they need to.
These days IDEs usually offer a configuration option to automate one way or the other, and some (I'm thinking of Visual Studio specifically) allow you to cut and repaste the code so that it will automatically be reformatted as per this choice, which is great, as long as the reformatting doesn't bugger up something else.
The other thankfully less common conformance reason is that you have one particular loud mouth Nazi that wants it their way, and in the interest of peace, the rest of the team conform, where as they really should just punch them on the nose.
Most languages handle either convention without any issues, but there are a few languages where parsing of the code actually leads to different results.
In PowerShell the "foreach" looping statement supports either but in a piped expression where "foreach" is an alias to the ForEach-Object cmdlet, the opening squiggly has to be on the same line or something completely different happens, that usually leads to a syntax error.
So given:
$list = @( 1, 2, 3);
Either of the following works fine:
foreach ( $item in $list)
{
$item + 1;
}
but in a piped expression
$list | foreach
{
$_ + 1
}
will error with:
ForEach-Object : Cannot bind parameter 'Process'. Cannot convert the "$_ + 1" value of type "System.String" to type "System.Management.Automation.ScriptBlock".
where as the following works:
$list | foreach {
$_ + 1
}
However I'm not sure this justifies having to write all your PowerShell this way, specifically because I wouldn't have written this code either way, but rather:
$list | foreach { $_ + 1 }
At the same time, because you get a error when you try to run the faulty code, testing will quickly identify where such an issue occurs. For PowerShell to misinterpret rather than report an error you would have to create a ScriptBlock object that I'm pretty sure you can't do in out-of-the-box PowerShell.
JavaScript is often used as another example because of how it supports optional semi-colons. If there is no semi-colon on certain lines the interpreter first add a semi-colon before compiling. Yes, this is a simplification but it will serve for the purpose of this discussion.
Issues occur when after adding the semi-colon, the line of code compiles and results in behaviour that was not expected. The problem is that the examples I have seen are obscure. For example, if you are returning an object from a function:
function createApple()
{
return
{
name : "Apple",
colour : "Red"
};
}
The "return" line is actually interpreted as "return;", the function then returns "undefined" and the next line of the function is never called.
The problem is this issue has nothing really to do with squiggly brackets, because the following is equally flawed for the same reason.
function createApple()
{
var apple = { name : "Apple", colour : "Red" };
return
apple;
}
The other problem with the first createApple() example is that the squiggly brackets here are not being used for statement block but rather an object expression.
The real issue here is that this sort of problem is best dealt with by testing, specifically unit testing and not coding conventions.
The strangest thing is that I've heard a number of claims used by both camps, some being really rediculous.
For example the claim of readability surely has to be a matter of personal preference, and I suspect in a lot of cases, depends on which method the programmer was first introduced to.
The claim by each camp that the other method makes the code read more like BASIC though has got to be the wierdest. There have been times when I've confused my C with C++, with Java, C# and JavaScript. But I can safely say I have never confused my code with BASIC.
I assuming of course that they mean a BASIC without line numbers like Vax Extended Basic or Visual Basic. But I can't believe in any universe that C will ever look like BASIC unless of course you wrote your C like this:
#define IF if (
#define THEN ) {
#define ELSE } else {
#define ENDIF }
...
IF result THEN
printf( "The result is true\r\n");
ELSE
printf( "The result is false\r\n");
ENDIF
Yep, that compiles and works in Visual C++ 2010 but even I would think it was BASIC at first glance if I didn't know what I was looking at.
And you know what? Now that I look at it, the readability is no worse than:
if ( result ) {
printf( "The result is true\r\n");
} else {
printf( "The result is false\r\n");
}
Hmm. Why is "reads more like BASIC" being considered an insult anyway?
My personal preference is for next-line but I equally accept someone's personal preference being same-line.
For me next-line works really well with one exception, the do-while construct. For example:
do
{
statement;
} while ( expr);
doesn't work for me but then neither does:
do {
statement;
} while ( expr);
Fortunately I don't use do/while very often.
Because of my preference for next-line I often here arguments specifically in favour of same-line, a couple of which are worth mentioning.
The first is that same-line saves paper when printing and screen space.
This is a pretty dated argument. I can't think of the last time I printed a piece of code, and the days of 80 x 25 screens are wll behind us. And back then we used to ship boxes of computer printouts every month by the truck load. I'm not sure saving the odd row here and there ever really provided any value.
The other argument is that same-line is the way it's done in "The C Programming Language" by K&R, considered the authoritive book on C.
With respect to this claim though I will quote the actual book states at the end of a short discussion on indention:
"The position of braces is less important, although people hold passionate beliefs. We have chosen one of several popular styles. Pick a style that suits you, then use it consistently."
I don't think I could have said it better myself.
If I was to ask which of these flavours you preferred most people I'm hoping would not be expecting everyone to answer the same. Nor would I expect them to accuse anyone who answers this question differently as being wrong.
Strangely enough, if I was to replace these flavours with the question of whether the opening curly brace should appear on the same line or the next line, then a lot of people seem to loose this concept of "personal preference" and break out into jihad or something.
The use of braces, curly braces or curly brackets if you prefer (I call them squigglies) actually dates back to before c. The language BCPL (1966) used $( and )$ to delimit a statement block to distinguish them from ( ) used in an expression. This influenced Ken Thomposon when he developed his language B (1969) that actually used { } and was the predecessor to C (1973).
C of course is the language we remember and is still widely in use today. So languages that use squiggly brackets are often described as C-style languages and include C++, Java, C#, Objective-C, JavaScript, PHP and Perl. That's a big chunk of the most commonly used languages in use today.
The issue boils down to whether you should write code like this (same-line):
if ( expr) {
... statements ...
}
or this (next-line):
if ( expr)
{
... statements ...
}
or more importantly, does it even matter?
There are a number of variants on top of this, one that I've encountered in a C++ codebase I had to work on that followed this 'philosophy':
If a single statement:
statement;
can be interchanged with a block of statements:
{
statement1;
statement2;
}
then surely the logical block idention for:
if ( expr)
statement;
should be:
if ( expr)
{
statement1;
statement2;
}
This particular indention isn't widely used and I've only encountered it in the one software house, but as an argument goes it's as valid as most others I've heard.
There are a few cases where there might clearly be a right or wrong answer and they mainly falls into 2 categories, conformance and language peculiarities.
For conformance, the most likely reason is the old "All our code is this way so this is the way we want you to do it". And this is a pretty valid reason. There is lot to be gained from uniformity in large code bases and most developers can make this sort of shift if they need to.
These days IDEs usually offer a configuration option to automate one way or the other, and some (I'm thinking of Visual Studio specifically) allow you to cut and repaste the code so that it will automatically be reformatted as per this choice, which is great, as long as the reformatting doesn't bugger up something else.
The other thankfully less common conformance reason is that you have one particular loud mouth Nazi that wants it their way, and in the interest of peace, the rest of the team conform, where as they really should just punch them on the nose.
Most languages handle either convention without any issues, but there are a few languages where parsing of the code actually leads to different results.
In PowerShell the "foreach" looping statement supports either but in a piped expression where "foreach" is an alias to the ForEach-Object cmdlet, the opening squiggly has to be on the same line or something completely different happens, that usually leads to a syntax error.
So given:
$list = @( 1, 2, 3);
Either of the following works fine:
foreach ( $item in $list)
{
$item + 1;
}
but in a piped expression
$list | foreach
{
$_ + 1
}
will error with:
ForEach-Object : Cannot bind parameter 'Process'. Cannot convert the "$_ + 1" value of type "System.String" to type "System.Management.Automation.ScriptBlock".
where as the following works:
$list | foreach {
$_ + 1
}
However I'm not sure this justifies having to write all your PowerShell this way, specifically because I wouldn't have written this code either way, but rather:
$list | foreach { $_ + 1 }
At the same time, because you get a error when you try to run the faulty code, testing will quickly identify where such an issue occurs. For PowerShell to misinterpret rather than report an error you would have to create a ScriptBlock object that I'm pretty sure you can't do in out-of-the-box PowerShell.
JavaScript is often used as another example because of how it supports optional semi-colons. If there is no semi-colon on certain lines the interpreter first add a semi-colon before compiling. Yes, this is a simplification but it will serve for the purpose of this discussion.
Issues occur when after adding the semi-colon, the line of code compiles and results in behaviour that was not expected. The problem is that the examples I have seen are obscure. For example, if you are returning an object from a function:
function createApple()
{
return
{
name : "Apple",
colour : "Red"
};
}
The "return" line is actually interpreted as "return;", the function then returns "undefined" and the next line of the function is never called.
The problem is this issue has nothing really to do with squiggly brackets, because the following is equally flawed for the same reason.
function createApple()
{
var apple = { name : "Apple", colour : "Red" };
return
apple;
}
The other problem with the first createApple() example is that the squiggly brackets here are not being used for statement block but rather an object expression.
The real issue here is that this sort of problem is best dealt with by testing, specifically unit testing and not coding conventions.
The strangest thing is that I've heard a number of claims used by both camps, some being really rediculous.
For example the claim of readability surely has to be a matter of personal preference, and I suspect in a lot of cases, depends on which method the programmer was first introduced to.
The claim by each camp that the other method makes the code read more like BASIC though has got to be the wierdest. There have been times when I've confused my C with C++, with Java, C# and JavaScript. But I can safely say I have never confused my code with BASIC.
I assuming of course that they mean a BASIC without line numbers like Vax Extended Basic or Visual Basic. But I can't believe in any universe that C will ever look like BASIC unless of course you wrote your C like this:
#define IF if (
#define THEN ) {
#define ELSE } else {
#define ENDIF }
...
IF result THEN
printf( "The result is true\r\n");
ELSE
printf( "The result is false\r\n");
ENDIF
Yep, that compiles and works in Visual C++ 2010 but even I would think it was BASIC at first glance if I didn't know what I was looking at.
And you know what? Now that I look at it, the readability is no worse than:
if ( result ) {
printf( "The result is true\r\n");
} else {
printf( "The result is false\r\n");
}
Hmm. Why is "reads more like BASIC" being considered an insult anyway?
My personal preference is for next-line but I equally accept someone's personal preference being same-line.
For me next-line works really well with one exception, the do-while construct. For example:
do
{
statement;
} while ( expr);
doesn't work for me but then neither does:
do {
statement;
} while ( expr);
Fortunately I don't use do/while very often.
Because of my preference for next-line I often here arguments specifically in favour of same-line, a couple of which are worth mentioning.
The first is that same-line saves paper when printing and screen space.
This is a pretty dated argument. I can't think of the last time I printed a piece of code, and the days of 80 x 25 screens are wll behind us. And back then we used to ship boxes of computer printouts every month by the truck load. I'm not sure saving the odd row here and there ever really provided any value.
The other argument is that same-line is the way it's done in "The C Programming Language" by K&R, considered the authoritive book on C.
With respect to this claim though I will quote the actual book states at the end of a short discussion on indention:
"The position of braces is less important, although people hold passionate beliefs. We have chosen one of several popular styles. Pick a style that suits you, then use it consistently."
I don't think I could have said it better myself.
Tuesday, January 1, 2013
Why I Will Never Buy Another Windows Phone
Two years ago I purchased a Windows Phone 7 mobile.
I was all excited because the main development language was C#, currently my favourite development language, and Charles Petzold was writing a book on how to program it, the same author that I learnt most of my early Windows programming from.
And then I learnt that if I wanted to write a program to run on my one phone, I had to pay Microsoft an anual fee for the privelege. Now I can write Android programs for free. If I was going to have to pay to have my phone unlocked, I might as well write for Apple and dust off that Objective C book.
Windows Phone 7 sales apparently were less than expected. I think they were after a 5% market share and I think they might have scaped in 3.5% but where I am, having a Windows phone is even rarer than that. Of course only Microsoft have the real figures but they only publicly talk about their over exagerated "License Sales" quantities.
Well Microsoft, here is the "secret" on how to sell a whole lot more real units. You have to be the earliest, the cheapest or the best. If you can do at least one of those your in with a chance. Windows Phone 7 did none of those.
Apple had already got there with the earliest. I really like the apple hardware and interface but I despise their locked down nature.
It just so happened that my wife purchased an Android phone at the same time which had a significantly cheaper price tag. During the last two years I've been able to compare many of the features:
File Connectability: My wife plugs her Android phone onto the computer and she can copy files directly to it. Alternatively she could copy files over our wifi. My Windows Phone 7 can only copy files via Zune (I hate iTunes but Zune is even worse than that) and then only that narrow set of files that Zune permits me (pretty well just Audio, Video and Photos). In fact if you want to copy a podcast or audiobook and have the phone remember where you are up to, you need to copy the file to the Zune podcast directory, and then change the genre to podcast. Also it lists and plays podcasts from newest to oldest but that order is problematic for audio books.
Extra Storage: My wife just plugs a micro SD into her Android phone as needed. Microsoft for some reason decided this was not allowed for Phone 7.
Email Connectivity: Windows Mobile 6.5 would work directly with the email client. This feature is not available in Windows Phone 7. Getting rid of features is not a way to keep existing clients.
Internet Sharing: My wife can use her phone to connect a laptop to the internet. My phone 7 couldn't for about a year until the 7.5 update from both Microsoft and then my hardware provider.
Cut and Paste: My wife's Android phone had this from the start. I had to wait till Microsoft decided that I was deserving enough for an update, and even then it doesn't work properly.
Custom Ring Tones: My wife can assign any MP3 file to play for each specific number in her address book. Again this feature had to wait till the Windows Phone 7 update, and then the file could not be more than 40 seconds long, had to be copied to a specific Zune directory and again had to have the genere changed to something rediculous.
Desktop and Theme: My wife can organise her desktop pretty well any way she wants, and has a variety of themes available. My Windows Phone 7 has these rediculously larged fixed sized icons, some of which animate for no apparent reason offering other than to distract you with noise (I'm talking about you "People" icon) and have this rediculous colour scheme. You can choose one colour from a very limited list. On the main screen you get white text on top of this colour, but in lower screens (specific individual address, you get really small text in this colour on top of a black background. So you have to choose a colour that contrasts with both white and black.
Application Availability:And here is the crux. For a phone to compete with Apple and Android it really needs to have as good a range of applications as they already have. But application developers will target those platforms with the market share first, and then only start to think about the other platforms. With the poor market share and end of life looming you might understand why your still waiting for Bad Piggies on Windows Phone 7.
SharePoint Integration: My Windows Phone 7 has a significant amount of SharePoint integration built in to it from the start but I've never used it and never wanted it. This sort of functionality should have been stuck in a free app that could be downloaded if needed and not taken up space, screen and time.
Music Player: My wife has and Android music player that allows her to create and organise playlists, sort her music in any order she wants and search by name. It is very easy to use and navigate. On Windows Phone 7 I have "Zune!" which just seems to fail on every one of these features.
Bluetooth Keyboard: My wife can use a bluetooth keyboard with her Android phone. While my Windows Phone 7 has bluetooth, they decided for some reason that an extenral keyboard was an uncessary feature and doesn't support it, which is why my wife has my bluetooth keyboard.
I could go on my point here should be clear. Windows Phone 7 was too little too late and too expensive.
Now with Windows Phone 8 and Windows 8 tablets starting to enter a very similar competitive market space, I see nothing to suggest Microsoft has learnt from it's mistakes.
I was all excited because the main development language was C#, currently my favourite development language, and Charles Petzold was writing a book on how to program it, the same author that I learnt most of my early Windows programming from.
And then I learnt that if I wanted to write a program to run on my one phone, I had to pay Microsoft an anual fee for the privelege. Now I can write Android programs for free. If I was going to have to pay to have my phone unlocked, I might as well write for Apple and dust off that Objective C book.
Windows Phone 7 sales apparently were less than expected. I think they were after a 5% market share and I think they might have scaped in 3.5% but where I am, having a Windows phone is even rarer than that. Of course only Microsoft have the real figures but they only publicly talk about their over exagerated "License Sales" quantities.
Well Microsoft, here is the "secret" on how to sell a whole lot more real units. You have to be the earliest, the cheapest or the best. If you can do at least one of those your in with a chance. Windows Phone 7 did none of those.
Apple had already got there with the earliest. I really like the apple hardware and interface but I despise their locked down nature.
It just so happened that my wife purchased an Android phone at the same time which had a significantly cheaper price tag. During the last two years I've been able to compare many of the features:
File Connectability: My wife plugs her Android phone onto the computer and she can copy files directly to it. Alternatively she could copy files over our wifi. My Windows Phone 7 can only copy files via Zune (I hate iTunes but Zune is even worse than that) and then only that narrow set of files that Zune permits me (pretty well just Audio, Video and Photos). In fact if you want to copy a podcast or audiobook and have the phone remember where you are up to, you need to copy the file to the Zune podcast directory, and then change the genre to podcast. Also it lists and plays podcasts from newest to oldest but that order is problematic for audio books.
Extra Storage: My wife just plugs a micro SD into her Android phone as needed. Microsoft for some reason decided this was not allowed for Phone 7.
Email Connectivity: Windows Mobile 6.5 would work directly with the email client. This feature is not available in Windows Phone 7. Getting rid of features is not a way to keep existing clients.
Internet Sharing: My wife can use her phone to connect a laptop to the internet. My phone 7 couldn't for about a year until the 7.5 update from both Microsoft and then my hardware provider.
Cut and Paste: My wife's Android phone had this from the start. I had to wait till Microsoft decided that I was deserving enough for an update, and even then it doesn't work properly.
Custom Ring Tones: My wife can assign any MP3 file to play for each specific number in her address book. Again this feature had to wait till the Windows Phone 7 update, and then the file could not be more than 40 seconds long, had to be copied to a specific Zune directory and again had to have the genere changed to something rediculous.
Desktop and Theme: My wife can organise her desktop pretty well any way she wants, and has a variety of themes available. My Windows Phone 7 has these rediculously larged fixed sized icons, some of which animate for no apparent reason offering other than to distract you with noise (I'm talking about you "People" icon) and have this rediculous colour scheme. You can choose one colour from a very limited list. On the main screen you get white text on top of this colour, but in lower screens (specific individual address, you get really small text in this colour on top of a black background. So you have to choose a colour that contrasts with both white and black.
Application Availability:And here is the crux. For a phone to compete with Apple and Android it really needs to have as good a range of applications as they already have. But application developers will target those platforms with the market share first, and then only start to think about the other platforms. With the poor market share and end of life looming you might understand why your still waiting for Bad Piggies on Windows Phone 7.
SharePoint Integration: My Windows Phone 7 has a significant amount of SharePoint integration built in to it from the start but I've never used it and never wanted it. This sort of functionality should have been stuck in a free app that could be downloaded if needed and not taken up space, screen and time.
Music Player: My wife has and Android music player that allows her to create and organise playlists, sort her music in any order she wants and search by name. It is very easy to use and navigate. On Windows Phone 7 I have "Zune!" which just seems to fail on every one of these features.
Bluetooth Keyboard: My wife can use a bluetooth keyboard with her Android phone. While my Windows Phone 7 has bluetooth, they decided for some reason that an extenral keyboard was an uncessary feature and doesn't support it, which is why my wife has my bluetooth keyboard.
I could go on my point here should be clear. Windows Phone 7 was too little too late and too expensive.
Now with Windows Phone 8 and Windows 8 tablets starting to enter a very similar competitive market space, I see nothing to suggest Microsoft has learnt from it's mistakes.
SharePoint Directions
I wanted to comment on what I see has been the general direction of SharePoint over the last couple of versions and the issues that arise from that.
Have you ever wondered why you can only change the master page in SharePoint once publishing has been turned on? I can see no technical reason. It seems simply that the UI component to do so was packaged with publishing because it wasn't there from the start and had to be packaged somewhere, even though it has nothing to do with publishing at all.
Of course this wouldn't be a problem except that once you turn on publishing you can't generate a site template, or if you do with any of the various workarounds, it is officially unsupported by Microsoft.
You can however change the master page in SP Designer regardless of publishing. In fact there are a whole bunch of features that should be in SharePoint that can only be done in designer. For exmaple if you want to include the standard left menu in a new page, you have to edit the page in SP Designer.
If you wanted SP Designer then you used to have to pay extra money. But many of these features should arguably have been in SharePoint itself. I think that's why Microsoft relented and decided to make SP Designer free, because that would be cheaper than to have to add all this functionality back into SharePoint directly.
The problem is that SP Designer includes a whole lot of functionality that would prevent it from being deployed to secured production environments. The last two large clients I worked for will not allow it to be deployed to anything higher than the developer environment.
And now it seems that Visual Studio is becoming the preferred tool for dealing with many of the things that SP Designer might have done, but there is no way I'm going to get VS deployed in an environment that already rejects SP Designer.
These tools are fine for more complicated and genuine development tasks but they are simply over-kill and over-complex for things like changing a master page or choosing a page layout that includes the left menu.
Have you ever wondered why you can only change the master page in SharePoint once publishing has been turned on? I can see no technical reason. It seems simply that the UI component to do so was packaged with publishing because it wasn't there from the start and had to be packaged somewhere, even though it has nothing to do with publishing at all.
Of course this wouldn't be a problem except that once you turn on publishing you can't generate a site template, or if you do with any of the various workarounds, it is officially unsupported by Microsoft.
You can however change the master page in SP Designer regardless of publishing. In fact there are a whole bunch of features that should be in SharePoint that can only be done in designer. For exmaple if you want to include the standard left menu in a new page, you have to edit the page in SP Designer.
If you wanted SP Designer then you used to have to pay extra money. But many of these features should arguably have been in SharePoint itself. I think that's why Microsoft relented and decided to make SP Designer free, because that would be cheaper than to have to add all this functionality back into SharePoint directly.
The problem is that SP Designer includes a whole lot of functionality that would prevent it from being deployed to secured production environments. The last two large clients I worked for will not allow it to be deployed to anything higher than the developer environment.
And now it seems that Visual Studio is becoming the preferred tool for dealing with many of the things that SP Designer might have done, but there is no way I'm going to get VS deployed in an environment that already rejects SP Designer.
These tools are fine for more complicated and genuine development tasks but they are simply over-kill and over-complex for things like changing a master page or choosing a page layout that includes the left menu.
Subscribe to:
Posts (Atom)