[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] new kaddressbook printing stuff commited
From:       Anders Lund <anders.lund () lund ! tdcadsl ! dk>
Date:       2002-11-30 23:06:06
[Download RAW message or body]

On Saturday 30 November 2002 13:50, Tobias Koenig wrote:
> On Sat, Nov 30, 2002 at 01:44:12AM +0100, Anders Lund wrote:

> Strange... Only the image is changed, why does the position of the label
> changes as well?

I'll look at it.

> > And I still think the sorting should have a page of it's own. If you look
> > at the atttached screenshot, the dialog page has a title and a helping
> > text which both deals with style. The central part of the widget is on
> > the other hand dealing with sorting. Not logical.
>
> Right, the text should be changed. But I didn't know what to write
> there.

> > There are some things that we can do to enhance that situation:
> >  * Enable the "Finish" button as soon as possible.
> > 	For example, there is no reason the user is _forced_ to see
> > 	the look and feel page for the detailled style, so the finish
> > 	button could be enabled before that. Even the style needn't be
> > 	changed, if we chose "Finish" on the first page, the default
> > 	settings for that will be used.
>
> IMHO it's to confusing when both, the next and the finish buttons are
> enabled. Isn't it the concept of a wizard that you get guided through
> the pages until the finish button appears?

> > 	To support this, we could put a page showing a sumary of the
> > 	settings before the action starts, and allow the user to save
> > 	"profiles" for printing to chose fom at the first page. We could
> > 	even provide some common profiles.
>
> Detailled style already save its settings, so that's not necessary IMHO.
>
> >  * Provide an alternative interface, for example a dialog using the janus
> > 	widget.
> > 	This would of cause be a lot of extra work, since it whould require
> > 	seperate widgets.
>
> Seperated widgets wouldn't be a problem, since we have seperated widget
> already now. I fear the kjanuswidget wouldn't fit into the concept of
> the kprinter useage.
>
> > Now that I'm at it, the page for, the detailled style breaks the wizard
> > idea as well, it should put the fonts and color settings on different
> > pages. I repeat here that the header used on that page is ridiculous, it
> > complies to no standard at all, the string should be put in the title for
> > the page. The author said that the string ("Detailled Style -
> > Appearance") is too long for that, but I disagree.
>
> I agree, the text of the 'blue on red' label should move to the title.
> But I wouldn't break the page into more because they belongs together.

I place my answer to all of the above here, as they are basically about the 
same issue:

Well, the idea of a wizard is that you guide the user through a process, one 
step at a  time. All the litterature I have read about it stresses that the 
"one step at a time" should be taken litterally.

If we do different, we break that rule, and our wizard will be different from 
most other wizards, and to my knowledge most attempts to follow the strategy 
of having more items on wizard pages has failed to work well.

I have been working with several wizards in which the finish button is enabled 
along with the next button, and had no problems with that. They appear in m$ 
office, in corel apps (i used their scanning/ocr tool quite often back in my 
windows days). Sometimes they have a hint on what the next page is about on 
all the pages.

I do know that this is not a perfect solution, but it is my opinion that it is 
better than breaking the idea of the wizard dialog.

As for saving profiles, they should save *all* information about the settings, 
allowing the user to replicate the exact action taken in one step, or use the 
settings as a base and change one or more of them. Typically, I'd set up a 
profile for printing a phone list, and change the group of contacts when 
using it, butkeep the colors. Doing so, the styles shouldn't need to save 
their settings seperately. 

This is a suggestion to change some things from how they are working now.
The reasoning is that since we aim at offering complex printing options that 
the user can even tweak, keeping this information is worth while for the 
user. It also saves repeatedly crawling a wizard, something that experienced 
users tends to hate.

As for the need of seperate widgets if we choose to provide an alternative 
interface for printing, it means
* in the wizard each page can only have _one_ concept/setting (setting four 
fonts is ok, setting one font and colors is not: fonts and colors are 
different concepts).
* in a wizard, the controls are completed with helping text and graphics
* in a normal dialog, each page can haveseveral concepts/settings


> > Another thing is that for the addressbook, maybe integrating the kprinter
> > dialog into the wizard would be worth considering. Some styles would
> > probably like to control the paper size, margins etc, for example a style
> > printing labels or pages in special formats for paper addressbooks and
> > so.
>
> Are you familiar with the kprinter class and could implement it?

I am confident that I can. I have been working with kdeprinter in two 
occations, the kate part printing and an app of my own. Since this is not 
really critical, I'll put it on my list with a low priority for now, and try 
exploring the options when I get some time ;)

> We shouldn't break all the pages in single ones, since we would get to
> much of them. Sorting and style selection can be in one page IMHO, but
> we should rename this page to something like 'appearance'.
>
> I would vote for doing the following things:
>   - fixing the layout bug in style page
>   - renaming the stylepage to something more fitting
>   - integrating the kprinter stuff if possible

As you can read from my above answers, I don't totally agree :)

I will not persue this issue though, if the kdepim team feels that we should 
use the current concept, I'll back out ot this discussion (for once ;). I'll 
even actively help implementing whatever is decided, the best I can.

-anders

_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]