Development: rate amount of work you've done

Just have realized that I subconsciously wrongly rate amount of work I've done.

<sorry, no translation yet>

До этого момента я (подсознательно) думал что чем больше функционала я навернул, тем больше полезной работы (измеряемой в человеко-часах, или в тысячах рублей) я проделал.

А вот и нет.
Сейчас пишу один проектик, в котором по сути 2 формы ввода. На одну из форм я уже потратил около 10 часов. Функционала, казалось бы, не так уж много, соответственно, и работы должно быть мало, и пользы для юзера. Но ключевой момент в том, что этой форму юзер будет пользоваться 80% времени от всей работы с программным продуктом. Следовательно, если она будет криво написана – ему будет тяжело работать. Если она написана нормально, но нет удобных подсказок, сложность выполнения самых частых операций не будет минимизирована - ему будет тяжело работать. Соответственно, мой вклад был недостаточно большим.

Следовательно, количество моей работы должно цениваться не только "в ширину" (т.е. количество фич в проекте), но одновременно и в "глубину" – проработанность одной конкретной фичи, её качество.

В связи с этим мысль:
как правило, работая над проектом, я держу перед глазами список тикетов (читай – фич), которые нужно выполнить. Возможно, вместо этого (или параллельно) стоит держать перед глазами аналогичный список use-кейсов? Так будет понятнее, какие моменты больше прорабатывать, а какие – меньше. Ещё заметил, что глядя на список подсознательно оцениваешь объём работ по количеству тикетов, а не по объёму каждого. Возможно, стоит попробовать систему списков, состоящую не просто из заголовков, а из кратких описаний тикета, где объём каждого описания визуально будет соответствовать объёму работы, которую нужно проделать. Можно организовать такое описание из множества заметок, например грубо вот так:

1. Сделать форму AAA: значение поля XXX проверяется по внешней системе YYY, поля XXX1 - в системе YYY1, поля XXX2 - в системе YYY2, поля XXX2 и XXX1 должны быть совместимы, поля ZZZ1, ZZZ2, ZZZ3, ZZZ4 должны быть совместимы


2. Сделать форму BBB: поле XXX должно провериться по значению AAA в базе.


3. Вывод выборки DDD: фильтр по XXX, YYY, ZZZ. Настраиваемый фильтр по DDD, EEE. Ajax-подсказки по фильтру EEE по существующим значениям

– наглядно, что на задачу 1 нужно больше времени чем на остальные, а на 2 больше чем на 1.

Пока мысль не довёл до конца, но подумаю на досуге о целесообразности такой "системы управления проектами для визуалов/сенсориков".

Dictionary for Openmoko

Few mounths ago I started to write a dictionary application specially for Openmoko/Neo Freerunner. StarDict dictionary format is it's base (few pieces of code is stolen from StarDict for dictionary pasing).

As Openmoko is full-featured Linux, there is a chance just to recompile StarDict, and get it working on the phone. I decided to write (almost) own implementation, because of the following:

1. GUI for mobile phone should differ from desktop's GUI. For example, this pdf-reader for Openmoko is actually a desktop application, just recompiled for ARM. Its GUI is not too convenient with small displays.
   


2. I like mobile dictionary to be fast and lightweight - it should start quickly - and work quickly, for example, in a foreign trip. GTK+ library is quite slow, as for me. So, I use (my favorite) FLTK2 for the interface.


3. I want special educational features: at least - word lists for remembering, later - text base, live pronunciation base, images, etc, in which you can find associations with words and phrases. Possibly - some kind of customizable language learning plan. The idea is to be able to learn languages when you have a bit of free time - in transport, subway, just by taking your FreeRunner from your pocket.


4. There is a selfish motive - to upgratde my own development level, to learn new instruments. (So, don't be scared, when you'll look at the code =) )

I've already implemented the following:

• Application skeleton (main architecture, considering all future features)


• Dictionary parsing, using a bit of StarDict code


• GUI - main panels, controls, tuning specially for small-screen, slow graphics mobile systems.




• Build for Openmoko (including FLTK2 and Boost libraries)

The app. interface based on screens, by functions. Switching between screens using buttons at bottom. The prototype looks like this:



First screen - word list (searching by first letters of fuzzy query).
Second - and main - word translation. Text can be scrolled by finger.
Third - bookmarks (your favorite word lists)
Fourth - text reader (optional)
Fith - settings. On the screnshot there is a list of loaded dictionaries, you can change translation order, switch on and off dictionaries.

Interface is finger-friendly. Side panel in lists (see bookmarks and settings) may be hidden. The button 'T' at the middle means translation of the word you selected in bookmarks or word lists, or you typed in input box at the second panel.

Feature list for the nearest releases:

• StarDict dictionaries, auto-scanning specified directories for dictionaries.


• Word searching by first letters, 'fuzzy query'.


• Clipboard-awareness, automatic clipboard translation (select word - switch to buffer - get translation)


• Pronunciation from wav-files (possibly, not in the first release)


• Word lists for remembering


• Simple text reader with word/phrase searching, tags and notes (optional).


• Complete configuration through GUI: font sizes, dictionary order, etc

Implementation: С++, Boost, FLTK2 (with few patches), some code from StarDict (requires glib and zlib).

I'm going to represent sources and binaries, when first beta version will be ready, presumably at the beginning of july. I think, i'll create also opkg-packets for available StarDict dictionaries.

I'll be glad to know your opinion:

• Do you need a dictionary for Openmoko?


• Are you interested in educational functions, or some other additional functions?


• Any suggestions about interface?