Mathieu Tozer's Dev Blog

To solve the problem of the computer getting to know what words you
know and thus don't know.
You have to distinguish between two or three ways:
1. Users completely learning from scratch.
2. Users who already know some words.
or
3. Users who know a little bit.

In case 1, you can afford to assume that the user, and the computer know nothing. Learning Finnish, for example. Therefore the original idea of building a list of words
that the user knows and doesn't know will work. This will be the case
in many cases, however as in

Case 2, the user is a native speaker or knows a bit already, and
therefore the computer wouldn't be able to be brought to that level
without a whole lot of kerfuffle, which would ultimately drive the
user away. So the solution I thought of while in the bath is to have
the user indicate the unknown words with a double click copy kind of
thing, so that the computer can know at least something about what
the user knows and doesn't know. The entire text can still be parsed,
and only the words that were clicked will be added to unknown, the
others to known. This should happens in both case 1 and case 2,
although in case 2 it is more integral to the solution (in a subtle
way).

So 一から users are assumed to know nothing, all words are new.
All other users are assumed to know everything, and required to
indicate the words they don't know. The words they don't indicate,
are assumed to be known.

Users should be asked what case they are during language setup, so
that Words knows how to handle text input, and how to manage the
dictionary.

After time, a text will automatically show words you know / don't
know, and then the list will refine as you click on individual words.

--

The above functioning must be thought out well, as it is very
important functioning for Words. Slowly I am ironing out the
difficulties. I think with this latest bath-think, I have tackled the
problem of getting the computer to know you.

--

It's important to distinguish between daydreams that are realizable
and those that are fantasy.

Words will function something like a 'history list' for a dictionary but will be more dynamic.

There will also be the possibility that languages without an existing word parser can be learnt with Words because of the single word feature. Then the software would just be used for unifying and managing and learning vocab lists, but that's still pretty good.

Parsers for Japanese and Chinese could be developed with a 'try and then see what you get' kind of algorithm. Much like the way I check these two, then that one, then the preceding one. And then look down the list of things to see what might fit.

So when a language is selected from the list that a parser or dictionary does not exist for, the program should behave appropriately, informing the user what functionality will be available.

The world wasn't ready for it

I think this is going to have to be called the writing semester. I have been doing so much! I think it's really good actually that I am overcoming the fear of things being out there and viewable.

Again, while I was in Swell this morning, I had another idea for a website.

--

Why not start a wiki or search for one that exists called 'Utopican Gadget' or something, and get everyone geeky to participate by submitting their ideas to it for the features they'd like to see. From this veritable sea of things that people might want, someone could take the ideas and make something really great.

The website would have
categories of device
Size
Screen type
Uses
What are the main things you would want to do with your device.

It would be nice to have all the eggs in one basket really, with phone, computer pda, camera (?) maybe not camera, music player all intergrated but small enough to carry everywhere. I wouldn't like to take it to clubs and carry it around, just so I could take photos. I would still want a separate, dedicated camera, and so would mose photographers really, but they could use it then to save and view the images.

It would suppost parralel computing through wireless networks, so that larger computing power can be used when they are around more computers.

The website would be some kind of open source development at the product proposal or specification level, which, let's face it, any geek can do just by sriting down their day dreams.

I wrote the following in a Café called Swell in Jan Juc this morning within the vicinity of 10 and 11. I was watching the few people around me, and writing my day dreams down.

--

Why does information about the news still get distrubuted on paper in trucks all around australia, when there are high speed information transferring wires connecting those places together?
It's the inertia of traditional ways of doing things I suppose. Maybe it isn't actually more cost effective to set up printing more locally, since the paper has to moced there anyway. The only benifit for electronic transfer would be gotten if people were reading it off screen as well. Which means that great advances in screen technology need to be made.

I just saw a woman push a door by the glass, try the other size, and then it had to be her friend to use the door handle. Now they're choosing Phillippa's bread. It was all I could do to stop from laughing.

But just like that man over there, it wouldn't be the same sitting down to some device to read the news, no matter how many sound clips and video files could be included

The people doing the writing and publishing is fine.
What I envision is a new way of reading it, and distributing it.

Wouldn't it be nice if you could just have a portible, mobile networked device with colour ePaper that, once subscribed to, would

Another person did it with that door! Maybe it has something to dowith the design of the door. Not everyone can be stupid! It must have something to do with the way the dor is designed...

would automatically deliver each subscription to you for reading on your device. Then, once the information (be it The Age, Will Shipley Blog, Dave Draper) is published it is swept around the globe to whatever device is subscribed to it. The software would be not a new or complex thing. Indeed technology exists for doing this already. It's mundane, hello, email, attachments, RSS, eBooks, etc etc, it's the hardware for once that is the limitation here. There is also some limitations with digital rights management that have been resolved through software.

Think about it, at the push of a button (Blogger said it: Push button publishing) information sweeps around the planet and into every crevise aware of it. People who want to know, will know.

Observign the man reading the newspaper though, you must be able to easily flick through the news to the sections you want. The sport, for example. Ads can appear in the same spots, if they want, adapted to the smaller screen of the device. But an easy slider could flick you thrugh sections or pagers, at the same time as showing you where you are in the document also, and how much more you've got to read.

People want to read while they eat too.
And people want to be able to tare out snippets of information and put them somewhere else. (Attached quick printer?) You might be able to prop it up on an angle so you don't have to lean forward and strain the back to read.

How do people feel about typing on a touch screen? Then the device could open like a book, or be used like a laptop as well. And have two large, low power consuming, ePaper screens for beautiful reading

Idea: Something tactile for scrolling? As opposed to on screen? Sony does this with the click wheel.What about a scrolling strap? Kind of like a tank track wheel to quickly flick pages with.

If there were touch screens, two of em, and a pen, then the device could be used for drawing on as well, like an electronic etch-a-sketch. Great for taking notes too, and then you can export them, print them, read them, whatever. Plus you can scribble on publications too, or read from one screen and take notes on the other.

This is a grat toastie.

What if the device were to hang from the hip, a stylish, durable device. It must have a handle.

Why not work a day down in Torquay during the summer?

Things should autosave, so that you don't have to worry about saving al the tie. Things are jst stored. Just like a pile of paper, really.

Downloaded publications are stored in a reading list or library. And displayed like a podcast is in iTunes.

If the ePaper is bendable, why not have one that fold in half. Then the curving crevice that the device makes would be a nice smooth surface along which to run a finger...

And with lightweight, high capacity (if a litle pricey) flash memory, you don't have to worry about heavy, moving hard drives stuffing up.

One problem I'm facing while developing this spec is that I don't know what I've already written, and what else needs to be written. I have to get into the habit of just noting down the ideas that will be fleshed out later, underneath the proper headings.

I am also not sure about whether I should have the GUI stuff under it's own section, or if it should be put in with the parts describing functionality.

In my opinion, these things often go hand in hand. Often I will be describing how something words, and since A Picture Tells A Thousand Words, wouldn't it be better to have a sketch or mock-up of what the screen shall look like before you describe the functionality within?"

Main Window
----Figure 1: GUI
----Functionality
--------Entering Texts
--------Creating new Word Lists
--------Creating Quiz

etc, etc

This is fine, but as the functionality changes and expands, so does the GUI, and as the GUI is developed, functionality changes. So all I can really hope to do is write and design as I can. The only real decision I made above was a structural one that could have been decided easily once it was all done and finished.

I had a dream last night, a nightmare actually (!!) because I dreamt that someone in Japan developed the exact software I am developing here. I dreamt I saw the ad, with this young Japanese boy using it to learn English.

It had this clean, white interface with large fat selectable wordlists on the right, and a larger list (or was it text display) on the left. There was two screens, the other displaying something or other. Manga, as it were.

I also dreamt about this Google Blog system where you could map flights by this beautiful user interface. You click your departure city and then on a smaller region map (all nicely coloured) you click the area you want to go to, then on the larger display the city. The thing automatically connects with all the flight drawn as different lines with different modes of transport leaping from point to point, and the view moves out to accommodate both cities in the one screen, plus a little bit more. It was so smooth. If you wanted to change your destination all you did was click a new spot.

The view ended up zooming out and up to show the whole glorious earth spinning on screen, with the moon, and all the particles and matter both objects attract as they spin through space.

It was envisioned that this would be utilised when flights started to the moon, and beyond.

I didn't see this in my dream, but I presume that once you clicked ok, or something, the flights you selected you wanted to take or had taken (already flown flight paths were shown in orange, future flights in blue) would be inserted into your blog.

The clock displays were cool too, which showed you when flights were available, if at all. They were an analogue clock display on screen that showed the hands, but faded orange in over the face where flights were not available. It was easy to see (in the dream) what the available time frame was.

It's something along the lines of the user interface that I had in mind for some kind of global transportation system. It was really breathtaking.

Oh the unconscious mind.

My other side project, classic has taken a back turn, but as I sat in the bath tonight and read a good old fantasy, ideas resurfaced.

Factor all that tricky internet stuff out to blogger. As I can see, it works so well, and multiple users are easily and beautifully added. It's free, and elegant. From within the program, all it needs to do is post to the blog, and then it can be reviewed by everyone easily online.

Full RSS feeds can bring the content back to the window of the user (?) for reading offline without actually opening a browser, and thus the software can manage its display.

There might be a few structural issues that would need to be changed in the semo-spec / proposal that I wrote some time ago so that they fit with this new framework. It makes the project alot smaller though, and easier to implement and think through if I ever wanted to develop it.

Users might actually even be adding their word lists from university or school to Words by copying and pasting a file or list. Words should be able to handle this easily and beautifully.

Also, in the very least, the user should be able to get a list of words types up with at least a space in between, without having to worry about columns, tabs, definitions etc etc and be able to put that straight into words to be parsed. The behaviour within words should be the same as if a new text were added. A new word list should be created and selected.

What if the software were able to recieve RSS notifications from web blogs and sites you read regularly, so that you can be remided... but then that wouldn't really help because people are already reading their RSS stuff from wherever they are and would probably not want to move away from that. But still the provisioning should be available for the program to parse web blog content (of course).

I just joined the ADC, with a student membership. All that is now stopping me from developing Words is the actual development. I have all the tools and the right environment to work with. Even when I come down to Torquay.

I can sit out the back here and look at nature, and create fire.

The deadline is the submission date for the 2006 WWDC student developer division application contest.
Let's call it Friday, May 13, 2006.

Try and aim for completion a month before that so that the application can be rolled out and be being used before then.
April 13th

Things to write for the specification.

--

The document should be concerned with how the software will work, down to each minute detail. I propose that the spec should be written with guidelines given by Joel on Software, and with also any information I can get from the guys at Delicious Library.

Each section will describe a part of the software in detail.

The general technique for writing will be to note down the functionality, then describe in more detail how that should be implemented.

Remember that there is a FINITE number of things at the end of the day that the software will do, so it's not a futile, endless task. While extra functions might be dreamed up and should absolutely be written down, they must also be critically thought about and then decided whether they should be added to the 'extra functions' list.

TIME LINE
There must be a time line for this project. It is as important as the spec.
Perhaps use the mythical man month as a reference.
The deadline is the submission date for the 2006 WWDC student developer division application contest.
Find out when that is, and try and aim for completion a month before that so that the application can be rolled out and be being used before then. This means that extra bugs can be ironed out, and also that the application has time to get moving.
There must be time to make a web-site for the app as well, and it has to be uploaded to a server where it can be downloaded by users.
Time to perfect and test the installation of the software needs to be carried out.

Time needs allocated to the beta testing in the field, and for the feedback to be accounted for.

--

The software specification should also be written for an audience (naturally), that being yourself, the implementer, but also someone who you might find and trust enough to look at the document, so that they can give you advice for what it is meant to do. If not this document, then future revisions of the product proposal should be shared.

Isn't it true that as you use RCS, you get an idea of how many hours you have been working on a document also? You just have to make sure that you check out and check in each document when you start and finish working on something, and try to only be working on one thing at a time.

--

Graphical User Interface
Colours, lists and fonts, sizes, layout, resize settings.
The minimised and maximised screens
Including Mock-ups.
Menus


Initial Settings and appearances.
The Key-Chord
Preferences pane
Services offered (In the services menu)

How the user interacts with the user dictionary..
How the user Adding adds a text to be parsed.
How the user trains the computer up to their level.
This could be changed as the implementation possibilities are considered.
How the user should interact with the application.
Word lists
Adding
Deleting
System defined
The behaviour of the word library


Taking quizes
Starting a quiz
selecting a quiz to take

Learning assistant tools
These use the words input into the program and help you learn them.

Periodic reminders
What they are for
How the wording should appear.
What the alerts look like and how they are shown to the user.
The options for the user to select from once the reminder has been given

Statistics
What statistics are available
How the stats should be shown to the user
What options are available for monitoring progress.
Graphical depiction of progress. How are they accessed?

Internet word search.
What the button looks like for this function.
Should this be set automatically to happen for all words.
Can this be a preference in the preference pane.
How does it happen in the background.
What happens when nothing is found.

Viewing Texts.

Work Sheet printing

--

The document should not be concerned with implementation limitations, but I should be aware of what is available and possible at the same time.

--

Mum and Dad were talking tonight after dinner about the future, and about how they can't go on supporting us kids forever. It's nothing that I don't know really, but yeah, I just want to note it down for motivation towards my own goals. I can do this.

I really like Joel's writing style.
To quote Why Write a Spec:

“As I worked through the screens that would be needed to allow either party to initiate the process, I realized that Aardvark would be just as useful, and radically simpler, if the helper was required to start the whole process. Making this change in the spec took an hour or two. If we had made this change in code, it would have added weeks to the schedule. I can’t tell you how strongly I believe in Big Design Up Front, which the proponents of Extreme Programming consider anathema. I have consistently saved time and made better products by using BDUF and I’m proud to use it, no matter what the XP fanatics claim. They’re just wrong on this point and I can’t be any clearer than that.”

The linked page is a good motivation and informational source on spec writing, which is my next task for Words.

...Design with "Cinema Paradiso" playing and in mind...

I am leaving the specifics of the GUI design to the spec document.
Let's get this proposal finished. I know why this product needs to be
made, and why it will be useful. It has passed the checking that a
normal product would pass. Actually as I'm the one making all the
decisions, the main purpose of a product Proposal is defunct.

But as the saying goes:

Plans are nothing. Planning is Everything.

Doing this piece of writing really brought up some of the issues that
I hadn't thought about yet. (I'm not posting it here 'cause it is
kinda, ahem, sensitive information) And needless to say more issues
will arise in the specs as well. They did in assignment 3 for
cse1402, all those areas in the menus, ideas where things could have
been done better. All that comes out in the careful planning and
writing of Proposals and Specs for an application larger than, say,
fridge master (see cse1301 final assignment).

---

Words Product Proposal v1.11 completed, but perhaps rather unpolished
and all together unprofessional. But who cares for now. It's late.
And I want to get onto the spec.

%It is tempting to dumb down what I want to achieve - put it into a little command line thing, however this is not the big picture that I want. Sure, creating something small is where I may start, but it should be one of the stepping stones towards the bigger, slicker application.

%Also, the small, command line program is not commercially viable. Only geeks are able to use this kind of software, no matter how good it is! And realistically, the average user has never opened the terminal.

%It is going to be hard work, and a lot of work, but just like Mike, I have to prove myself to the community of what I am capable of. I must be careful. So the purpose of these design analysis documents are meant to define what I am setting out to achieve, and as software engineering goes, make me see the bigger picture so that I can break it down into smaller components, and then smaller components again, which are of manageable size.

I'm trying to build up a 'port folio' of translations I've done so that I can show I have experience. I'm currently working on translating poems written by a friend of mine in Japan who I have asked to set up a web log for him to post his thoughts and reports from Japan.

The Words project.

I am also looking for a new job.