[Bitpim-devel] New Calendar GUI Prototypes screenshots

[d***@netzero.com]

While looking into GUI prototypes for the new calendar dict, I found that by subclassing phoneentryeditor.Editor I could efficiently capture existing Calendar Entry Editor and create a new one that supports all new fields. This new editor already came with support for notes, categories, wallpapers, and ringtones; and the rest of the other fields can be added with a couple of tabs. I'm attaching some screen shots of the prototypes for your reviews & comments.

-Joe Pham

[Roger Binns]

Post by d***@netzero.com
I found that by subclassing phoneentryeditor.Editor I could efficiently capture
existing Calendar Entry Editor and create a new one that supports all new fields.

Good thinking!

I would drop the up down stuff and only leave one of each type of item
(which also means dropping the add/delete).

The other thing it may be possible to do is not have tabs, but instead
just have each item one after the other with a scrollbar down the
side.

If you want some reading material, I highly recommend Alan Cooper's
stuff:

http://www.cooper.com/articles/art_goal_directed_design.htm

This gets you thinking the right way, and even mentions
calendaring. (You might note that I stole the main calendar
from there :-)

http://www.cooper.com/content/insights/cooper_books.asp

The "Inmates" book is excellent for showing how to do good
gui design. The "About Face" book is nitty gritty details.

BTW I also detest the controls used for Start/End. Almost anything
would be better!

Roger

[Steven Willis]

Post by Roger Binns
The other thing it may be possible to do is not have tabs, but instead
just have each item one after the other with a scrollbar down the
side.

I personally like tabs and would rather not scroll down a page, I like
to see all related controls at once if at all possible. Tabs are nice
because they give the user a reminder of the different sections they
might want/need to fill out as opposed to one long screen that has
most options hidden out of view with no indication of what is
currently not visible and whether the user needs to fill out.

-Steven Willis

[Roger Binns]

Post by Steven Willis
I personally like tabs and would rather not scroll down a page,

In this case it depends on just how much vertical real estate
woudl be consumed if the items are one after the other as
opposed to being in seperate tabs. It seemed to me that they would
all fit on one page without scrolling, which would be better
than tabs. Once scrolling is involved then things favour tabs.

The reason I came up with the original suggestion of one page
was that the screenshots showed not much real estate being
used at all. I wanted the first tab to also include a summary
of all the other tabs so I didn't have to go and look at
each one seperately. But one of Alan Cooper's principles is
that wherever you provide output, allow it to be input as well.
(It is very frustrating when programs show you stuff but don't
allow you to edit what they show you(*)) So I figured the actual
edittable fields from the other tabs would fit, and then would
conform to this principle.

(*) And that would be the answer to what is wrong with the current
phonebook main display. At some point I have to figure out how
to make it editable in addition to the existing entryeditor dialog.

Roger