nxskok asks an excellent question in his comment: in summary he found that the width formatting seemed wrong.
Good comment because firstly yes, it was wrong. And more importantly, he exposed an excellent flaw in my development process. Java is famously a language which is write once, run everywhere. With web technologies it's more like write once, test everywhere, swear a lot, and recode in several.
HTML 5 technologies in general and CSS specifically behave differently in different browsers, different operating systems, and (if you're using them) different devices. So if you want your code to run everywhere, ideally you should test every possible environment that you want to support. As a starter, you should cover the "big 4" browsers: chrome, firefox, safari, and IE. Preferably in multiple versions [1] and on different operating systems.
In a nutshell, good catch[2]: almost certainly nxskok was using a different browser from me, and so found the different behaviour.
Increasing the width will work, but is just one potential solution. If you're thinking of mobile devices, you might find that the whole frame is too big to fit in a phone screen and so a better approach is to reduce the font size and make all the items smaller.
Here's a screen capture showing these updates, and I've also changed from pixel width to %. I used the built-in debugging tool that comes with Google Chrome, which is my preferred debugger for HTML 5 and demonstrates how powerful the on-the-fly change functions are.
To launch the debugger, from Chrome click the right-hand customize and control menu, then Tools -> Developer tools. Click the Elements tab to see the HTML and CSS side by side.
[1] IE 7, 8 and 9 are notoriously different from each other. If IE 6 is on your list, you might want to review the IE6 Security problems
[2] In my defence, I did spot the problem and increase the width in Dojo part 2, but I failed to retrofit the fix into part 1, so I'll take the rap
Sunday, 29 September 2013
Thursday, 19 September 2013
Why you are right, even when you're wrong
As a wrongologist, I was inspired by Andy Brodie's Monty Hall problem blog to ponder a little about why the problem causes so much debate.
The thought procedure that people apply instinctively is this: there are 3 doors, and the contestant has a random choice, therefore the odds are 1/3 for each door. Even after one door is opened, it makes no difference whether you stick or change, the remaining 2 doors you can choose from are equally likely so, as one door has been removed, the odds are now 50:50.[1]
These statements are correct and the logical deduction (as stated) is correct too, but the answer is (sorry) not. What's missing is that this analysis is incomplete. The contestant makes random choices, yes, but there is another actor in the scenario. In an entirely random world, where the presenter also made a random choice, the odds for the last door would stay at 1/3, and between the remaining two doors they would effectively be 50%[1] but some of the time the presenter would open the door which hides the cadillac.
In actuality, the presenter deliberately chooses not to open a door hiding a cadillac, and so introduces a non-random factor which is why the instinctive answer is not the right one after all.
When the contestant makes the original decision, the odds were 1/3 for the chosen door, and 2/3 for the remaining two doors. But when the presenter opens a door, this guarantees that the contestant knows for certain what is behind the open door. And by implication, this has shared information about what's behind the unopened door. In other words, the contestant knows that - of the original 2/3 case - the cadillac will be behind the 3rd (unchosen) door 100% of the time. 100% of 2/3 is: 2/3.
The odds for the first door haven't changed, they are still 1/3rd. 100% of 1/3rd. But now you're comparing a 2/3 choice with a 1/3 choice, and that is not equal at all.
So the verdict is in: you should opt to change your mind and pick a door that you originally rejected, which the presenter also rejected. Because while your rejection was made at random, his was not: he knew something when he rejected that door.
Or to put it another way, your facts were correct, your logic was correct, and you may still have come up with the wrong answer because you missed a factor. I work in an environment where wrongness is punished so heavily that if you make an incorrect deduction, you are considered to have used up your question-asking tokens for the day, or possibly the week or the month.
It's a scary world out there, full of pedants, perfectionists, and a loud get-it-right-first-time brigade. Wrongologists of the world, join me in standing up for your wrong deductions. When you go away and muse over the most important question: where you went astray, you will learn more than if you had originally come to the right answer quickly. I also believe that getting things wrong and understanding why is an important step in understanding a customer point of view and how easy (or otherwise) our output is to consume. Wrongologists, welcome to your new role as consumability champions.
[1] I know, I know, I'm mixing percentages, ratios, and fractions. Life is more exciting if you live on the edge.
The thought procedure that people apply instinctively is this: there are 3 doors, and the contestant has a random choice, therefore the odds are 1/3 for each door. Even after one door is opened, it makes no difference whether you stick or change, the remaining 2 doors you can choose from are equally likely so, as one door has been removed, the odds are now 50:50.[1]
These statements are correct and the logical deduction (as stated) is correct too, but the answer is (sorry) not. What's missing is that this analysis is incomplete. The contestant makes random choices, yes, but there is another actor in the scenario. In an entirely random world, where the presenter also made a random choice, the odds for the last door would stay at 1/3, and between the remaining two doors they would effectively be 50%[1] but some of the time the presenter would open the door which hides the cadillac.
In actuality, the presenter deliberately chooses not to open a door hiding a cadillac, and so introduces a non-random factor which is why the instinctive answer is not the right one after all.
When the contestant makes the original decision, the odds were 1/3 for the chosen door, and 2/3 for the remaining two doors. But when the presenter opens a door, this guarantees that the contestant knows for certain what is behind the open door. And by implication, this has shared information about what's behind the unopened door. In other words, the contestant knows that - of the original 2/3 case - the cadillac will be behind the 3rd (unchosen) door 100% of the time. 100% of 2/3 is: 2/3.
The odds for the first door haven't changed, they are still 1/3rd. 100% of 1/3rd. But now you're comparing a 2/3 choice with a 1/3 choice, and that is not equal at all.
So the verdict is in: you should opt to change your mind and pick a door that you originally rejected, which the presenter also rejected. Because while your rejection was made at random, his was not: he knew something when he rejected that door.
Or to put it another way, your facts were correct, your logic was correct, and you may still have come up with the wrong answer because you missed a factor. I work in an environment where wrongness is punished so heavily that if you make an incorrect deduction, you are considered to have used up your question-asking tokens for the day, or possibly the week or the month.
It's a scary world out there, full of pedants, perfectionists, and a loud get-it-right-first-time brigade. Wrongologists of the world, join me in standing up for your wrong deductions. When you go away and muse over the most important question: where you went astray, you will learn more than if you had originally come to the right answer quickly. I also believe that getting things wrong and understanding why is an important step in understanding a customer point of view and how easy (or otherwise) our output is to consume. Wrongologists, welcome to your new role as consumability champions.
[1] I know, I know, I'm mixing percentages, ratios, and fractions. Life is more exciting if you live on the edge.
Tuesday, 17 September 2013
Dojo - part 2 (non-module)
In order to integrate HTML with dojo, a few changes are needed.
Here's the HTML, I've highlighted what's different:
First I've added a link to the 1.9.1 level of dojo. This isn't best practice, but it makes life a lot easier to begin with and it should "just work".
Then I've added a link to a javascript file, HelloDojo.js, you'll find the contents below.
And finally, the <form> tag has gone, so I've added a class of "formSurround" which I can use to set CSS characteristics.
Here's the dojo code, which you should save in js/HelloDojo.js
The first part of the file is the require sections, this loads the entities we need from the dojo libraries. In this case, we've got explicit calls to:
Dojo on listens for events - in this case, someone clicking a mouse
Dojo dom gives a handle onto the dom, it's used to look up entities on the page
Dojo domReady is a critical dependency to make sure the page content is loaded in the right order
I've included references for on and dom, but it's a sign of how fast dojo is moving that once you get into the world of modules, you won't use them again. However, a lot of the code snippets around on the web predate modules and still rely on older dojo style, so it's useful to understand how they work and even more important to understand how things don't work if you get them wrong.
Without domReady, on is called before myButton has been created, and so although the page looks normal, nothing will happen when you click "submit". If you load up an error console, you'll see an error like this:
Uncaught TypeError: Cannot read property 'on' of null
The error looks slightly different depending on which browser you're using, there's a good list of the symptoms for this and several other dojo errors in Debugging dojo
The CSS has changed slightly from the previous version:
The most important change is that now we've lost the form object, we need to find something explicit to hang the formatting off. That something is the formSurround class.
Now that we're in dojo, the button formatting has changed, so I've reinstated a border radius.
Now that we're in HTML 5 territory, I can use some of the new CSS 3 wonderfulness, so I've added a box shadow to the text box: mostly just because I can!
And finally, we've got a new response entity on the page, I've formatted it with respText to make things a little prettier.
The final result looks similar to the previous HTML:
... with the added bonus that you should see a result when you click "Submit Form"
I've loaded this code into JsFiddle
Here's the HTML, I've highlighted what's different:
<!DOCTYPE html>
<html>
<head>
<title>Hello Dojo</title>
<LINK href="css/hello.css" rel="stylesheet" type="text/css">
<!-- Note that the http prefix below is not best practice -->
<script src="http://ajax.googleapis.com/ajax/libs/dojo/1.9.1/dojo/dojo.js" dojoConfig="isDebug: true, parseOnLoad: false, async: true"></script>
<script src="js/HelloDojo.js"></script>
</head>
<body>
<h3>Hello Dojo</h3>
<div class="formSurround">
<label for="myText">Enter your name here</label>
<input id="myText" class="text" type="text">
<button id="submitButton" class="button" >Submit Form</button>
</div>
<div id="response" class="respText"></div>
</body>
</html>
<html>
<head>
<title>Hello Dojo</title>
<LINK href="css/hello.css" rel="stylesheet" type="text/css">
<!-- Note that the http prefix below is not best practice -->
<script src="http://ajax.googleapis.com/ajax/libs/dojo/1.9.1/dojo/dojo.js" dojoConfig="isDebug: true, parseOnLoad: false, async: true"></script>
<script src="js/HelloDojo.js"></script>
</head>
<body>
<h3>Hello Dojo</h3>
<div class="formSurround">
<label for="myText">Enter your name here</label>
<input id="myText" class="text" type="text">
<button id="submitButton" class="button" >Submit Form</button>
</div>
<div id="response" class="respText"></div>
</body>
</html>
First I've added a link to the 1.9.1 level of dojo. This isn't best practice, but it makes life a lot easier to begin with and it should "just work".
Then I've added a link to a javascript file, HelloDojo.js, you'll find the contents below.
And finally, the <form> tag has gone, so I've added a class of "formSurround" which I can use to set CSS characteristics.
Here's the dojo code, which you should save in js/HelloDojo.js
require([
"dojo/on",
"dojo/dom",
// Needed so that on isn't called too soon
"dojo/domReady!"
],
function(on, dom) {
myButton = dom.byId("submitButton");
on(myButton, "click", function(evt){
/* Don't submit the form!! */
evt.preventDefault();
evt.stopPropagation();
var myInput = dom.byId("myText");
var response = dom.byId("response");
var helloStr = "Hello ";
response.innerHTML = helloStr + myInput.value;
});
});
"dojo/on",
"dojo/dom",
// Needed so that on isn't called too soon
"dojo/domReady!"
],
function(on, dom) {
myButton = dom.byId("submitButton");
on(myButton, "click", function(evt){
/* Don't submit the form!! */
evt.preventDefault();
evt.stopPropagation();
var myInput = dom.byId("myText");
var response = dom.byId("response");
var helloStr = "Hello ";
response.innerHTML = helloStr + myInput.value;
});
});
The first part of the file is the require sections, this loads the entities we need from the dojo libraries. In this case, we've got explicit calls to:
Dojo on listens for events - in this case, someone clicking a mouse
Dojo dom gives a handle onto the dom, it's used to look up entities on the page
Dojo domReady is a critical dependency to make sure the page content is loaded in the right order
I've included references for on and dom, but it's a sign of how fast dojo is moving that once you get into the world of modules, you won't use them again. However, a lot of the code snippets around on the web predate modules and still rely on older dojo style, so it's useful to understand how they work and even more important to understand how things don't work if you get them wrong.
Without domReady, on is called before myButton has been created, and so although the page looks normal, nothing will happen when you click "submit". If you load up an error console, you'll see an error like this:
Uncaught TypeError: Cannot read property 'on' of null
The error looks slightly different depending on which browser you're using, there's a good list of the symptoms for this and several other dojo errors in Debugging dojo
The CSS has changed slightly from the previous version:
body {
font-family: "Trebuchet MS", Helvetica, sans-serif;
}
h3 {
margin-left: 130px;
}
.formSurround {
margin-left: 20px;
width: 320px;
background-color: #e0e0e0;
height: 85px;
padding-left: 15px;
padding-right: 15px;
}
div {
padding-top: 10px;
}
.button {
margin-top: 20px;
float: right;
font-size: 17px;
border-radius: 4px;
}
.text {
-moz-box-shadow: 10px 10px 5px #888;
-webkit-box-shadow: 10px 10px 5px #888;
box-shadow: 10px 10px 5px #888;
}
.respText {
color: blue;
margin-left: 20px;
margin-top: 10px;
}
font-family: "Trebuchet MS", Helvetica, sans-serif;
}
h3 {
margin-left: 130px;
}
.formSurround {
margin-left: 20px;
width: 320px;
background-color: #e0e0e0;
height: 85px;
padding-left: 15px;
padding-right: 15px;
}
div {
padding-top: 10px;
}
.button {
margin-top: 20px;
float: right;
font-size: 17px;
border-radius: 4px;
}
.text {
-moz-box-shadow: 10px 10px 5px #888;
-webkit-box-shadow: 10px 10px 5px #888;
box-shadow: 10px 10px 5px #888;
}
.respText {
color: blue;
margin-left: 20px;
margin-top: 10px;
}
The most important change is that now we've lost the form object, we need to find something explicit to hang the formatting off. That something is the formSurround class.
Now that we're in dojo, the button formatting has changed, so I've reinstated a border radius.
Now that we're in HTML 5 territory, I can use some of the new CSS 3 wonderfulness, so I've added a box shadow to the text box: mostly just because I can!
And finally, we've got a new response entity on the page, I've formatted it with respText to make things a little prettier.
The final result looks similar to the previous HTML:
... with the added bonus that you should see a result when you click "Submit Form"
I've loaded this code into JsFiddle
Dojo - part 1 (HTML and CSS)
In the beginning, W3C created HTML[1]
, a standard which converged rapidly on HTML 4[2],
and became the engine of the web that we all learned to use during
the noughties. And W3C saw that it was good. Good, but there was
something missing. The static nature of HTML 4 gives a very clear separation between the presentation of a web page and the content behind it, but it turns out that it's useful to have more dynamic capabilities in the presentation layer.
And W3C said let there be javascript.
And the Dojo foundation created the dojo toolkit, a javascript
library which provides a more dynamic web experience.
To learn more about dojo, you'll need to start with some HTML. Here's the source for a basic HTML page of a simple form with CSS formatting, in future blogs I'll start adding dojo code to it. If you want to run the code yourself:
- Open a text or code editor (for example notepad, eclipse, or aptana)
- Save the HTML in a file called anything.html
- Save the CSS in a file called hello.css, under a directory called css
- Double click or drag and drop the HTML file into a browser and check out the results
<!DOCTYPE html>
<html>
<head>
<LINK href="css/hello.css"
rel="stylesheet" type="text/css">
<title>Hello Html</title>
</head>
<body>
<h3>Hello Html</h3>
<form>
<div>
<label for="myText">Enter
your name here</label>
<input id="myText"
class="text" type="text">
<!-- note that there's no
action on this button, so it (intentionally) doesn't have any effect -->
<input class="button"
type="submit" value="Submit Form">
</div>
</form>
</body>
</html>
I've pointed out some of these features as they show in the web page in the screenshot below. Here are a few brief explanations of code which doesn't directly control a visible feature:
<div> is a division or section. It's mostly here now because the HTML 4 specification mandates it, but we'll use divs a lot more with dojo.
<!-- --> is a comment.
<!DOCTYPE>, <html>, <head>, and <body> are required by the HTML (4.01) specification
Here's the CSS for formatting:
body {
font-family: "Trebuchet MS",
Helvetica, sans-serif;
}
h3 {
margin-left: 130px;
}
form {
margin-left: 20px;
width: 290px;
background-color: #e0e0e0;
height: 85px;
padding-left: 15px;
padding-right: 15px;
}
div {
padding-top: 10px;
}
.button {
margin-top: 20px;
float: right;
font-size: 17px;
}
If we were using HTML 4, we would need
to make the submit button perform an action, but then we'd also have
to go and write the backend web service. Instead, we'll take another
direction and add javascript in the form of dojo, so for now this is
just a form that doesn't actually do anything.
If you see a result like this, it's
because your HTML page can't find the CSS page, make sure you have it under a folder called css:
The successful result looks like this:
I've loaded this code into JsFiddle
Footnotes
[1] Tim Berners-Lee and the W3C
developed HTML 1, which was never published, and HTML 2, which was.
[2] Technically 4.01, which was
formally released in December 1999, and is still in use today,
although it is being overtaken now by HTML 5 [3]
[3] I generally use figures and
references from Wikipedia, where I am a paid up personal member (but
not an employee)
Subscribe to:
Posts (Atom)




