[BitPim-devel] Main screen ideas 1of2

[Simon C]

I've been experimenting with a layout change for the main view.
I replaced the tabs with a icon list.
I'm not convinced that this is any good, but I thought I'd share.

Some screenshots attached some using xp sytle and one classic style.
There were no changes to the panels, I only replaced the
notebook, they are now mounted in a splitter.


Thoughts?

Simon

[Roger Binns]

I certainly agree that the current BitPim user
interface sucks. One program whose interface I have
always liked is fma:

http://fma.sourceforge.net/preview.php

I do remember seeing an "outlook bar" component for
wxPython a while back, although I can't find it now.

Another avenue to consider is that Mark Hammond is
busy integrating Python into XUL Runner (the environment
that Firefox and other Mozilla projects are built on).
That may provide for a better gui than wxPython.

Roger

[Joe Pham]

They are functionally equivalent. The new one has better looking icons, and it appears that users would have scroll to get to the top/bottom icons.

-Joe Pham




_____________________________________________________________________
Call Anyone, Anytime, Anywhere in the World - FREE!
Free Internet calling from NetZero Voice
Visit http://www.netzerovoice.com today!

[Joe Pham]

That GUI seems to be Windows only. Any specific features about it that you like?

-Joe Pham




_____________________________________________________________________
Call Anyone, Anytime, Anywhere in the World - FREE!
Free Internet calling from NetZero Voice
Visit http://www.netzerovoice.com today!

[Simon C]

Post by Joe Pham
They are functionally equivalent. The new one has
better looking icons, and it appears that users
would have scroll to get to the top/bottom icons.

The existing interface is functional so I was not
trying to change this. the intent was to present the
information in a different way that would provide an
improved user experience.

I'm planning to experiment with a tree view (with
icons) and try to intoduce a toolbar with more
buttons. Toolbar access to commonly used items (like
send/get data) would make it easier to use.

Simon

[Simon C]

I certainly agree that the current BitPim user interface

Borrowing some style ideas from fma I've replace the icons with a tree view,
it looks better I think.

If we do decide to get rid of the tabs, each panel can be cleaned up as time
allows, I don't think we have to do the whole change in one go. We can also
add a standard way for each panel to hook into the tree view (e.g. SMS and
call history) so that we don't have two tree views on the screen as the same
time (the file view may be an exception to this perhaps.
I think we also need more buttons on the toolbar.


Simon

[Roger Binns]

Post by Simon C
Borrowing some style ideas from fma I've replace the icons with a tree view,
it looks better I think.

I do too! BTW where did you get the icons?

Post by Simon C
add a standard way for each panel to hook into the tree view (e.g. SMS and

It should also possible to have the same item multiple times in the tree view.
For example in addition to the phonebook entries, there could be a node
named groups which each group as a child and phonebook entries in that
group as a further child.

It would be really nice if we could make it all drag and drop aware
so for example you could drag a ringer and drop it onto a phonebook
contact to associate that ringer with that phonebook entry.

There is also the question of how far we take this all. I think it
is possible to get rid of the menu bar! All the items in the menus
could be somewhere in the tree.

Post by Simon C
I think we also need more buttons on the toolbar.

This is where we could reasonably use the help of a usability expert.
Does anyone actually use the toolbar?

Roger

[Simon C]

Post by Roger Binns
I do too! BTW where did you get the icons?

http://tango-project.org/Tango_Icon_Gallery

Open source too! Except for the phone root which is a loosely based on
something I found in a google search.

Post by Roger Binns
It should also possible to have the same item multiple times
in the tree view.
For example in addition to the phonebook entries, there could
be a node named groups which each group as a child and
phonebook entries in that group as a further child.
It would be really nice if we could make it all drag and drop
aware so for example you could drag a ringer and drop it onto
a phonebook contact to associate that ringer with that
phonebook entry.

It would be great to go that far, we would have to implement it in a way
that could be done gradually, upgrading different panels individually. Some
thought would need to go into the interface between the common tree and the
panels and the object types we use for drag and drop. Did I read somewhere
that drag has problems on non-windows with wxPython?

Post by Roger Binns
There is also the question of how far we take this all. I
think it is possible to get rid of the menu bar! All the
items in the menus could be somewhere in the tree.

I think windows users are used to menus and toolbars, it would look a bit
odd without one.

Post by Roger Binns

Post by Simon C
I think we also need more buttons on the toolbar.

This is where we could reasonably use the help of a usability expert.
Does anyone actually use the toolbar?

Several years ago I used to design GUIs for windows apps for my sins, I had

[Michael C.]

Simon,

I like what you have done. However, I'm a bit concerned with the one
icon for "detect phone". The magnifying glass has the the international
meaning of "find" or "search"; in the context of the PhoneBook, as you
picture shows, the end-user may think it means "find contact". Since
you seem to be pretty good at creating/editing the icons (I give you
much credit, since I don't), maybe if you put a phone under the
magnifying glass, that may alleviate any confusion.

Just my $0.02. Take or leave it. ;)

Michael C.

PS: GREAT WORK!

Here is a screenshot of a toolbar I've been working on. The icons are from
left to right
Get data, send data, add, delete, phone info, detect phone, settings,
autosync and help.

[Simon C]

I'd like to go ahead and check in the toolbar changes I sent out the preview
for yesterday.
I'll hold off until tomorrow for feedback. I'm going to try to improve the
detect phone icon first.
This will not include the tree view.

Simon

[Roger Binns]

Post by Simon C
I'll hold off until tomorrow for feedback. I'm going to try to improve the
detect phone icon first.

Don't forget to update help/3rdparty.htd

Roger

[Simon C]

the one icon for "detect phone". The magnifying glass has
the the international meaning of "find" or "search"; in the
context of the PhoneBook, as you picture shows, the end-user
may think it means "find contact". Since you seem to be
pretty good at creating/editing the icons (I give you much
credit, since I don't), maybe if you put a phone under the
magnifying glass, that may alleviate any confusion.

I followed your suggestion. This is the toolbar that will likely appear in
the next build.

Simon

[Michael C.]

Post by Simon C

the one icon for "detect phone". The magnifying glass has
the the international meaning of "find" or "search"; in the
context of the PhoneBook, as you picture shows, the end-user
may think it means "find contact". Since you seem to be
pretty good at creating/editing the icons (I give you much
credit, since I don't), maybe if you put a phone under the
magnifying glass, that may alleviate any confusion.

I followed your suggestion. This is the toolbar that will likely appear in
the next build.
Simon

Simon, that looks awesome! Good job!

Michael C.

[Simon C]

Post by Simon C

Post by Simon C
Borrowing some style ideas from fma I've replace the icons

with a tree

Post by Simon C
view, it looks better I think.

I do too! BTW where did you get the icons?

Post by Simon C
add a standard way for each panel to hook into the tree

view (e.g. SMS

Post by Simon C
and

It should also possible to have the same item multiple times
in the tree view.
For example in addition to the phonebook entries, there could
be a node named groups which each group as a child and
phonebook entries in that group as a further child.

I propose changing the main screen to be a tree view similar to the
screenshot I sent out.
The implementation...
The main window object will loose all of it's phone code, it will only
provide the splitter frame, tree view and routing for menu and toolbar
events, it will create a phone object to add to the root of the tree.
The tree view will contain a root node representing a phone object. The
phone object will be a class that contains references to all the wigets for
the phone and will manage the leaves (widgets) under its node in the the
tree view (it's parent). The phone class will contain references to the
database and configuration options for its phone. This allows for multiple
phones to be managed in the same tree view at some point in the future.
A new class will be created to serve as a base class for the widgets, this
will provide access from the widget to the tree view, this will allow the
widget to add objects to the tree rather than having to create their own
tree view (SMS, call history and fileview for example). It will also provide
context sensitive popup menus for the tree, controlled by the widgets which
will publish the menu items for their parts of the tree and subscribing to
the events.
It should be possible to upgrade the widgets one at a time, rather than all
at once, the original widget code will work in the new design without
change. Change will only be required to access the new features.
The phonebook widget will take advantage of the tree view to show things
like categories and allow new categories and contacts to be added via the
popup menu in the tree.
Drag and drop will be added in the widget base class, this will allow a user
to move contacts from one category to another easily or add a ringtone to a
contact. Widgets would subscribe to drop events and provide object hit test
results, the base class would maintain a list of drag and drop data types to
allow the widgets to handle custom objects. When multiple phones are
supported, drag and drop will be supported between phones.

The initial version of the change would provide no addition functionality to
the user, just a look and feel change. Improvements to the individual
widgets would follow as time allowed.

I have not done any of this work, the screenshots I sent out were barely
functional. I'd like to get approval from everyone before I do anything
more. This is a big piece of work, but I think it will be worth it. The
approach described will allow it to be done incrementally, and allow
multiple developers to work on different portions simultaneously. The result
will be bitpim having a really good looking front end to match the best of
what is out there.

Comments?

Simon

[Joe Pham]

Post by Simon C
The main window object will loose all of it's phone code, it will
only provide the splitter frame, tree view and routing for menu and
toolbar events, it will create a phone object to add to the root of
the tree. The tree view will contain a root node representing a
phone object.

That's a significant departure from the current BitPim design, which has been thoroughly tested, all for a new GUI. Any advantages of this approach? If you want to pursue this, I'd suggest creating a new branch and go at it.

-Joe Pham



_____________________________________________________________________
Call Anyone, Anytime, Anywhere in the World - FREE!
Free Internet calling from NetZero Voice
Visit http://www.netzerovoice.com today!

[Simon C]

Post by Simon C

Post by Simon C
The main window object will loose all of it's phone

code, it will

Post by Simon C
only provide the splitter frame, tree view and

routing for menu and

Post by Simon C
toolbar events, it will create a phone object to

add to the root of

Post by Simon C
the tree. The tree view will contain a root node

representing a

Post by Simon C
phone object.

That's a significant departure from the current
BitPim design, which has been thoroughly tested, all
for a new GUI. Any advantages of this approach? If
you want to pursue this, I'd suggest creating a new
branch and go at it.

The main advantage will be to allow multiple phones to
be displayed at the same time. The worker thread would
not be moved, I am only thinking about moving the
database and configuration related stuff.
This does raise the question of how a user would
choose which phone data to send to their phone if
there was more than one phone data available, there
would have to be some way of specifying the active
configuration.

Simon