Tuesday, March 20, 2012

Comments on Windows Phone

I bought a Nokia Lumia 710 yesterday, my first smart-phone. I've tried the iPhone quite a bit and have an iPad. I've had a play with some Android phones. Somehow Microsoft have managed to make the best mobile OS out there.

I've completely changed the default layout to be entirely people centric rather than app or service centric. It makes people with iPhones look like geeks. This came from Microsoft! Inconceivable!

Things I like:
  • Metro UI. It's taking over the whole Microsoft design world. It's superb. It looks good and easy to use. Someone really needs to apply it to computer games (I'm not talking about GUI in games, but the games themselves. Imagine a FPS in a Metro style!)
  • Unobstrusive. I don't like how iOS interrupts my activity with irrelevant messages.
  • Linking to all my accounts was simple. Way easier than setting up my Google mail account on the iPad, for example.
  • Very responsive. It loads apps very quickly. It doesn't have the clunk of iOS (and it's not even multi-core yet).
  • It's a social OS. My phone revolves around people rather than mediums (calls, SMS, email), services (Facebook, LinkedIn) or apps (pictures, music, etc.)
  • The base apps are really good. E.g., Nokia Drive, Office, Xbox games.
  • The back button is really useful.
Things I don't like:
  • Animation on the people tiles. These tiles should not change unless I have a new message. I know who the person is by their picture, I don't need the OS to switch between their picture and their name. Bad user experience Microsoft! (But it's the only poor decision I've seen thus far.)
  • The link between a person and their e-mails doesn't work correctly. On a person's profile it will say I've received emails from them. When I click to see the list it lists all emails, not the emails coming solely from them. Surely this isn't an uncommon use case! Weird.
  • I'm not convinced that the screen-size is large enough to use the keyboard effectively. I feel like I'm getting more typing errors than I'd expect. This could be an OS issue, screen issue, general issue with smart-phones or a me issue.
  • Needs Skype integration. (Microsoft, you might not have noticed that you own Skype!)
  • Needs Google+ integration. I know few use it, but most of my geeky friends do.
  • The search button uses Bing. (Useless)
I'm glad I bought a Windows Phone over an iPhone or an Android phone. The integration is great. I really dislike the app hell (too many apps all over the place!) I get with Apple. The design is much better too. I still shudder when I bring up Notes on the iPad. Ick! But WP is still playing catch-up with Google and Apple. I want the future Apollo features today. Just imagine what people will be able to do with app to app communication.

Thursday, March 8, 2012

Computer Reversi, Part 1.5: The Thor database (Othello tournament files)

As part of my research into Reversi, I looked for an archive of games. The only substantial one I found is called the Thor Database. It's an archive of Othello games by French archivers. They have archived are over 100,000 games. You can download the game databases here.

My initial motivation for finding an archive was to have a easy way to unit test my code to ensure it implemented the Reversi rules correctly. If the game engine could play through 100,000 games and calculate the final score, that's a good indication that the rules have been implemented correctly. An archive can also be used for book openings. I have another idea for the archive too, which I will hopefully reveal soon.

My Reversi source code has a Thor project with a bunch of methods and classes for extracting the data for whatever nefarious needs you may have. I don't think there is any code in C# on the net for this, so maybe one day it'll be helpful for someone. Maybe. (Probably not.)

The file format documentation is challenging to understand because it is written in French. I have translated (thanks to Nuz and google translate) the core elements of the document in the section below. The aspects I found challenging were:
  • Interpreting the meaning of the black player's score (I needed to calculate the score as the final check to ensure my rules were working)
  • Interpreting the way they recorded the individual plays
  • Converting elements of a byte-array to a 16-bit integer. (The data are stored as little-endian. One way: BitConverter.ToInt16(new [] { thorArray[i], thorArray[i + 1] }, 0).)
To calculate the Black Score:
  • Get sum of black pieces and the sum of white pieces;
  • Whoever has the most pieces wins;
  • The winner adds to the sum the number of empty squares;
E.g., Black has 44 pieces, White has 8 pieces; Black's score is 56. Or, Black has 13 pieces, White has 35; Black's score is 13. In the case of a draw, Black's score is 32 (as the empty squares are shared between Black and White, 32 is the only possible score for a draw). I still haven't figured out what it means for Black's score when the game ends before neither player can play a piece. The score seems inconsistent. This only occurs in 406 of 107,473 games. (Not a big deal.)

The data, such as Word and Longint, are stored in Intel format, ie the lowest byte first. There is a game file for every year. Games are stored in any order, but normally grouped by tournament.

Database header fields
All files in the database Wthor have a header of 16 bytes, followed by a number of game records all having the same size. The header consists of the following fields:
  • Century file was created
  • Year file was created
  • Month file was created
  • Date file was created
  • Number of records N1
  • Number of records N2
  • Year of game
  • Parameter P1: size game board
  • P2 parameter: type of games
  • Parameter P3: depth
  • X1 (reserved)
Game fields
  • Tournament Number
  • Number of Black player
  • Number of White player
  • Number of black pieces (true score)
  • Theoretical score
  • Move list 
The plays are stored in chronological order. Row number (1-8) and column (A-H) can be derived from the following operation: column + (10 * row). E.g., a1 = 11, h1 = 18, a8 = 81, h8 = 88.

Tournament file
Each record (26 bytes) is an array of characters terminated by a binary zero. The effective length is 25 characters. There is a 16 byte header for this file. 

Player file

Each record (20 bytes) is an array of characters terminated by a binary zero. The effective length is 19 characters. There is a 16 byte header for this file.

Monday, March 5, 2012

JavaScript - Accessibility and Useability

There has been talk at work about having to provide non-JavaScript alternatives for any of our web-pages that use JavaScript. A few people were suspicoius of this idea and given that we're using MVC3, they were finding it very difficult to implement functionality without JavaScript. Below is the document I created after reading compliance info on the net. You can also download as a Word doc.

JavaScript - Accessibility and Useability on the Web

Below are the relevant sections of documents concerning JavaScript and its impact on website accessibility and useability. I have checked documents relating to accessibility compliance under Australian law, compliance for US law and more general accessibility sites. In the conclusion, I explain a public website’s responsibilities regarding JavaScript and accessibility/useability.

Disability Discrimination Act Advisory Notes

It is important for developers to understand that in many cases the accessibility of a particular technology will be determined by how it is used. For example, it is widely considered that JavaScript can be implemented so as to be accessible. However, JavaScript can also be used in ways that are inaccessible, particularly if full keyboard support is not provided.
Ten Common Web Accessibility Failures
1. Failure to include appropriate text descriptions (such as “alt-text” labels) for images;
2. Failure to provide accessible alternatives when using a visual CAPTCHA;
3. Failure to use technologies (such as Flash and JavaScript) in ways that are accessible;
4. Failure to use HTML features appropriately to indicate content structure such as the hierarchy of headings;
5. Failure to explicitly associate form input controls with their labels;
6. Failure to ensure sufficient difference between foreground (text) colour and background colour;
7. Failure to identify data tables with Summary or Caption, and failure to mark-up data tables correctly;
8. Failure to provide a way for users to disable content such as advertisements from flashing rapidly (rapidly-flashing content may cause seizures in susceptible individuals), and failure to provide a way for users to stop a page from auto-refreshing;
9. Failure to ensure that web pages can be used from the keyboard (that is, without the mouse);
10. Failure to alert the user to changes on a web page that are triggered automatically when selecting items from a dropdown menu.

How to Meet WCAG 2.0

1.1 Text Alternatives: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
1.2 Time-based Media: Provide alternatives for time-based media.
1.3 Adaptable: Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
1.4 Distinguishable: Make it easier for users to see and hear content including separating foreground from background.
2.1 Keyboard Accessible: Make all functionality available from a keyboard.
2.2 Enough Time: Provide users enough time to read and use content.
2.3 Seizures: Do not design content in a way that is known to cause seizures.
2.4 Navigable: Provide ways to help users navigate, find content, and determine where they are.
3.1 Readable: Make text content readable and understandable.
3.2 Predictable: Make Web pages appear and operate in predictable ways.
3.3 Input Assistance: Help users avoid and correct mistakes.
4.1 Compatible: Maximize compatibility with current and future user agents, including assistive technologies.

(No specific mention of JavaScript.)

Migrating from WCAG 1.0 to WCAG 2.0

Ensure that pages are usable when scripts, applets etc are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.
[Priority 1]

Issue is addressed as part of "Conformance requirements".

NB: WCAG 2.0 does not require alternative to be always provided for JavaScript etc. But nominated "accessibility supported technologies" must be used in a way that is accessible.
Conformance requirement 4: Only accessibility supported technologies are relied on to satisfy the success criteria. AND
Conformance requirement 5: If technologies that are not accessibility supported are used, they do not stop users accessing the rest of the page.

Accessible Rich Internet Applications (WAI-ARIA) 1.0

New technologies often overlook semantics required for accessibility, and new authoring practices often misuse the intended semantics of those technologies. Elements that have one defined meaning in the language are used with a different meaning intended to be understood by the user.

For example, web application developers create collapsible tree widgets in HTML using CSS and JavaScript even though HTML has no semantic tree element. To a non-disabled user, it may look and act like a collapsible tree widget, but without appropriate semantics, the tree widget may not be perceivable to, or operable by, a person with a disability because assistive technologies may not recognize the role.

Screen readers vs JavaScript

JavaScript Enabled = 98.4%, Disabled = 1.6%

10.4% of respondents to the October 2009 survey indicated that they have JavaScript disabled in their web browser. As respondents submitted responses to this survey we detected the presence of JavaScript. We found that very few respondents had it disabled or unavailable in their web browser. Of the 19 respondents with JavaScript disabled, 12 were using Firefox (presumably with the NoScript add-on enabled) and 5 were using Lynx with Linux.

Creating Accessible JavaScript

Making JavaScript accessible involves looking at the following issues. Each of these will be discussed in the next lessons.

·         When using event handlers, use only those that are device independent (e.g., do not require the use of the mouse only).
·         Content and functionality that is provided through scripting must be made accessible to assistive technologies.
·         Web pages that utilize scripting must be fully navigable using a keyboard.
·         JavaScript should not modify or override normal browser functionality in a way that may cause confusion.
·         When JavaScript cannot be made natively accessible, an accessible alternative must be provided.

Accessible forms: Guidelines, examples and accessible JavaScript tricks.

So what will you find here?
·         A list of form guidelines based on current and on-going research into accessibility, usability and web standards.
·         Simple examples of accessible forms including: a login form, a search form and a contact form.
·         Examples and help on each form element.
·         Styling forms with CSS.
·         Using accessible inline JavaScript to aide form functionality.
·         Using accessible JavaScript with the DOM to aide form functionality.
·         A comprehensive list of external form related articles and resources.


W3C, Australian law and US law either make no comment on JavaScript or state that JavaScript is acceptable as long as accessibility is maintained.

WCAG 1.0 required that non-JavaScript alternatives were required. WCAG 2.0 does not have this requirement. In compliance with WCAG 2.0, we are permitted to implement pages that would not be useable without JavaScript so long as they remain accessible.

The guidelines at http://webaim.org/techniques/javascript/ and http://www.websemantics.co.uk/tutorials/accessible_forms/ can assist in determining how to ensure the use of JavaScript on a website is accessible.