Mathieu Tozer's Dev Blog

Parser
Basically a parser in words (for language X) just breaks a 'text'
into word tokens, and feeds them into the dictionary.

The software should support the imports of the following file formats:
1. HTML
2. txt
3. rtf
4. pdf

Pre-processing of Texts
Aim to separate the pre-processing of texts from their original
format into 'parser friendly' format to reduce the complexity needed
by the parser itself. Ie HTML tags removed, rtf and pdf made into
plain text.

Ideally, the object passed to the parser must be a uniform plain(est)
text. English and English like languages should be in plain text.

User's Dictionary
An important Component. Each user has one for each language they
learn. Holds all the words a user knows at any given knowledge level.
Might be conceptually divided, and depending on performance and
implementation details, it might be a bundle of separate entities
acting together.
Input: a newWord object

reflects information held in word lists throughout the application.

Language Definition Dictionary.
This is a regular dictionary. One freely available and distributed
needs to be obtained.
Input: Word

Output: Definitions / translations.

There ought to be one of these for each language available in words.

The distributed installation should come with provisioning for at
least English to English, English to Japanese, Japanese to English,
and if available English to Chinese, Chinese to English. Other
European languages, if available, should be provided.
Available Dictionaries:
http://www.csse.monash.edu.au/~jwb/j_edict.html
http://www.mandarintools.com/download/cedict_readme.txt
http://www.csse.monash.edu.au/~jwb/j_jmdict.html

These dictionaries are constantly being updated. Updated dics should
be included in updates of words, if the option is not available for
the dict to be downloaded separately and installed.

Text Suggestion Lists.
This small and easily implemented feature might just be a list of
links to places where users can get good texts to start reading in
their chosen language.
Sources might include
1. Major Newspapers
2. Wikipedia(s)
3. ...

The list would be shown in an independent window pane for users to
jump from.

I would imagine that the major performance issues will arise with the
parser and the looking up of words in large dictionaries, however if
you look at WordLookup then it need not be too demanding.

//BrainWave//

What if I were to leave the parsing 'socket' unplugged for a moment,
so that I can concentrate on getting the MAIN functioning of the
program working, which is the management of word lists and
dictionaries. This I can now see will be what I will spend most time
on. I must specify the interface of the components so that plugging
any number of language parsers into it later is easy and well
planned, but I think the other functioning is more important.

The idea of an open socket for something to be plugged is an
interesting one. What if I did have the option for even third parties
to plug the socket?

What about a technical dictionary included as well so people can use
it to learn programming languages and look up technical definitions,
or things like cocoa terms and stuff.

Same goes for medical dictionaries.

There are a few different components that need to be implemented.
Developing them as components means that I can reduce complexity,
yada yada yada all that OO stuff I learnt and know. What I want to do
is identify these components, and decide which order I am likely to
implement them in.

The second step is to zoom in closer than that and take a look at the
insides of these components.

So let's think about what I need to implement for Words.

English Parser

Dictionary Files

I need to work out how words will look up translations
How it can search Google and other resources
How it can search Spotlight
How it can export sound files into iTunes.

User Interface for
Main Window (maximised + minimised)
Flash Cards
The recording pane

There are certain resources that I can use. These should be in a
bookmark in Safari and a bookshelf in your room!

Technology Guide (printed)
Apple UI guidelines
Objective-C handbook (printed)
Cocoa Recipes (book)
Online resources
Peer Blogs.

/*Write for the blog, but don't worry too much about the formatting.
Have a potential audience so write structured, organised, and neatly,
but don't fuss!*/

Bugger it.

I know what I want to do. I know what I want to build. Some of it
will grow natively, a lot will come from the specs.

I'm going to enter the implementation phase.

I read Harry Potter mostly, but I was thinking after about writing in
English for Yoshiro's Blog, then translating to Japanese from the
English, and then having Yoshiro fix it up.
Good for translating and language skills.

I was also day dreaming about my future house in the country, and the
wonderful open glass rooftop bathroom it's going to have. Glorious.

Month	Week
10	1	Specification
	2
	3
	4
11	1	Implementation
	2
	3
	4
12	1	Implementation
	2
	3
	4
1	1
	2
	3
	4
2	1	Beta Testing
	2	Website
	3
	4
3	1	Debugging
	2
	3
	4	Marketing
4	1
	2	Roll out on Market
	3
	4	Submission
5	1
	2	Deadline May 13th

I have stalled momentarily... but I think that's because I don't know
where to focus next.

I must compile a definitive list of 'extra features' that go along
side the main functioning, and decide which ones should be
implemented, and then decide how they will fit into the final
solutions (buttons, menus, functioning, movements on the screen etc).

I should keep in mind how the user is ultimately going to use the
product.

So once I get all the features spec-ed out, then pretty much all of
the spec writing should be completed really.

And then there's the implementation... Now THAT'S going to be
challenging!

I was wondering whether sending off that email to Cris at plasq was
worth it but the other day I got a really enthusiastic and
encouraging reply! It IS nice to find someone closer to home who is
like minded.

Mac Developers are a rare thing indeed!

Anyway so he wants to catch up over a beer sometime. Cool.

This is the cycle that I envision Words will go though. It is cyclic and heads back onto itself for second and third releases of software.

A pang of excitement ensued after my first attempts at Interface
Builder Mocks. They're pretty basic, and not entirely what I have in
mind, but it's cool to see what is going to be possible realised
right before your eyes.

It also allows me to feel what the UI would feel like to use, in both
expanded and contracted state.

Ideas only! Don't get ahead of yourself.

It needs to be [little] something that can be put on all varieties of icons.

It is NOT the company logo.

Which reminds me if I want to make some money out of this I'm going to have to form my own company!

∫
Integration

Butterfly [ glossy ]
Disco Ball
Something GLAM
sunglasses [ cool ]
lipstick (mouth)
barbell [ work ]

For Payment:
Something completely blatant in it's imperialistic money grabbing ideals to kind of make a jest but also make it clear
The queen's head. A coin etc.
Little scrawled stuff for icons.

The user interface and icons should look very fresh an OS X-ey yet slightly bookish.

I would like something shiny and silver, something very me...

And I want the company symbol on top f the DMG files all proper like!

In Woodstock:

Apple has developed affordances for objects already, widgets, for
example. You don't want to overwrite these by making up your own
unless it's a REALLY good idea.