Mathieu Tozer's Dev Blog

THE ANTI GLOBALISATION SOCIETY'S GUIDE TO INTERNATIONAL TRAVEL
1. Getting there...


Idea for a book. Required plenty of research but would learn a lot about how the world works these days.

Apple has done a nice job of factoring out a lot of the hard stuff,
so that developers can spend more of their valuable time
concentrating more on what is unique to their applications. This
amounts to not re-inventing the wheel.
I have realised this while writing assignment 3 for CSE1402. At first
before I had discovered that it was OK to use OS X as the 'Target
Operating System', I went into all this detail describing what a
'drawer' was

... A special kind of window ...

But it turns out that all that was just wasted air. I could have just
said

'See Interface Builder's documentation on what a drawer is'

Since that's what the implementors are going to be using to actually
build the project.

So here's what I've learnt from this.
1. Know what system you are designing for from the start.
2. Know the system's capabilities well, preferably before you start
designing, so that you don't re-invent the wheel, as I said.

I suppose all this 'learn before you start' is easier said than done,
considering you learn a whole lot by doing. But it's something to
keep in mind and be primed to.

Know your tools!

RCS is like a simple project wide time machine that let's you travel
back in time to any version of your document and code, with a simple
command. Using it even for personal projects is essential.

I have to use the subjects I am learning and connect them to this project.

Some notes about the techdoc project.
\LaTeX{}

MUST HAVE 20 Glossary items
runn aspell with English spelling on it.

Large % is expression. get it read out loud, or someone else to read it. Can read it out loud yourself.

User manual.
We want a walktrhough.
We want to walk the user through. You have to have a bucketload of figures.

We want mathematical formulae.

Follow the question and you'll get top marks.

The updates come right from the mothership. It's the same as how apple updates their software, it's all automatic and on the next sync it ends up just filerting down on into the iPod. That buisiness model works, and it makes the user more aware of where the updates come from. They come straight from Apple. Knowing this is good for the company's image.
Words should do this to. It's always nice to have a program update itself after politely asking if you would like to do it.

I'm thinking just for portability's sake, that the 'sketches' for my UI's should be done on the newton. It's a great diagramattical tool!!

Some ideas I just had while having a bath.

1. When you need to have some ideas, have a bath.

2. Words should have a customer feedback sheet.
What would you like to do with this software, but can't?
If you haven't registered, can I ask why?

3. The User should be able to just be reading a web page, and in the case of a non native speaker, think 'I wonder if I will be able to read all this?' and hit a key chord or something as simple. Then Words should come to the rescue.

4. The minimised version of the program is just the list. It it titled:
In this text
You don't know these words
You've seen these words
You know these words
And any other category dream-able. Emphasis on the words you don't know.

5. Click on the maximise button and you get the full fledged program window, with you customised word lists on the left, and the actual words on the right, with all their characteristics showing. 

6. When Words 'comes to the rescue' as described above, it whirs into action 'reading' the document. The words should pop up onto the screen as they are found and then dictionaries searched for translations / meanings. Known words in the document should have their sentences poised and ready to show the user where they saw the word, if they happen to have forgotten it and had to look it up again. 

7. It's important not to make all these things pop up all over the screen all the time. It gets really annoying and looks tacky. （ちゃち）

8. When it comes to final naming, DON'T call it iXXX or MyXXX. WeWords? WeLearn? WeeLearn?? Anyway nothing I really have to think about now.

9. When there's an Asian language parser, tablets could be used to practice characters, and give feedback on them, or store them so that the user can mark their progress.

10. Statistics should be available to the user on the progress

Adding Behavior to a Cocoa Program

A thought that keeps coming to mind:
What if more than one person in the house uses a computer? And they both want to use Words to learn a language, let's say English. Let's hypothesise.

We have Hiroshi, who is learning English. There's 1 Mac in the house. Hiroshi's sister sees how much Hiroshi has improved his English, and wants to use the software too.

She has two options, depending on whether the software handles multiple users. If it doesn't, then she is going to have to sign into her own account on the Mac. But what are the chances of her having her own account on that computer?

Would it not be better to ask who the user is when the program launches the first time, and then when Hiroshi's sister comes around, she can go to the menu and ask to 'add new user' and away she goes. She could alternatively open the program in her own userspace as well.

So there you have it. The reasoning and decision made. Words will have support for multiple users, so that non-tech savvy families can still use the software.

I'm devouring this document. Chapter By Chapter. It's well written and with my tech doc primed eyes I am appreciating even the beautiful and functional typesetting.
I am learning about what the possibilities for my Words software are exactly, and indeed for any programming software I have.

See the core data programming guide.
It looks as though this can be used now to create the Model part in the Model-View-Controller Paradigm easily and even graphically.

Opened
[1] Mac OS X Technology Overview
[2] Apple User Interface Guidelines

All available from The OS X Developer Connection Website.

[1] Read pp 1 - 32 (Chapters 1 & 2)
Learnt that developing for OS X isn't all about Cocoa. There are other Application Environments like Carbon, Java, AppleScript, WebObjects, BSD and X11. All things I have heard of before, but now I know better who they are for and what kinds of applications they could make, for example. There are Plug-Ins, Widgets, Agent Applications (the dock, and iChat notifications, for example) and Screen Savers.

I can use this list of technology components when designing Words. This document will be a good reference for the design of my applications. It will teach me how I can use the technologies in OS X to create great products.

It pointed out that there is alot of information out on the net. #1 = Developer Documentation. This source alone is enough refrence and reading material!

With my recent greater understanding of OSs, the layered look of OS X that chapter 1 offered was interesting because I knew about the Core OS services (kernel, device drivers, low level stuff). The other layers really structured in my head the conceptual levels of the whole system. From Core OS to Core services (strings, process management), App Services (HTML rendering, speech synth), Graphics (Quartz, OpenGL), App Environments (Cocoa, Java) User Experience (Aqua, appearance) - this one more of an abstraction really.