[openbeos] Re: inconsistency?

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Thu, 23 Sep 2004 01:55:16 +0200 CEST

Adi Oanca <e2joseph@xxxxxxxxxx> wrote:
> Axel Dörfler wrote:
> > Although I am not really a friend of the bubble windows in Windows, 
> > I 
> > think they have at least one advantage over your 2nd suggestion: it 
> > doesn't change the window position.
>       That's not really an advantage. We all know BeOS has a poor layout 
> system. If you have 2 instances of a window you won't see the first 
> one 
> unless you move the second. To avoid this, applications need to 
> calculate a proper position based on god knows what algorithm which 
> take 
> into account previous spawned windows.
>       Personally I don't like the absolute window placing system, an app 
> can't know where it's best to lay out its windows. I Like very much 
> the 
> cascade placing system followed by best fit and edge ones.
>       If you remember we talked on IK list about a layout system and said 
> it 
> will definitely be a part of R2 if not R1.

There is a subtle difference between placing "a" window and several 
windows. I prefer to find things where I left them, and I am annoyed if 
windows pop up at a place where I didn't expect it.
Now, when you talk about opening a new StyledEdit window (the second), 
there is definitely a need for proper placement.
But in one way, I think I must agree (probably) with Jonas: we 
shouldn't do too much. Subtle changes to improve the user experience.

> > It also makes sure that the user 
> > can grasp the whole title and origin of that window.
>       Part of the title will be available in my 2nd suggestion. Also a 
> part 
> of thew new window will there. Think it's better than just a title. 
> You 
> know, the smallest graphical representation it's better than a text.
>       And where would the new window be durring this time?

Sure, it would definitely be nice to see the whole window. That's why I 
would like to combine those things, ie. have that unobtrusive bubble 
window and a transparent overlay of the window asking for user 
attendance.
When we are working in a full screen window, we couldn't move those 
windows around anyway.

> > It could go away after a while, and it could also have a button 
> > that 
> > moves W' to the foreground.
> > Combine that with the transparency effect of yours and a hot key 
> > that 
> > the user can press during that fade out time (and afterwards as 
> > long as 
> > the bubble is open) to bring that window to front.
>       Do not agree with that. User is busy with something. We have 
> notified 
> him, let him finish its work.

No, he doesn't have to be that busy. We'll notify him about an event, 
and *he* should be the one in charge to decide what to do next. A hot 
key will ease switching to the new window for him without having to 
leave the keyboard.
I would suggest to reuse the current app/window switcher hot key for 
this (ie. ctrl-tab). We just have to make sure that that new window is 
placed next.

>       When he's done, surely will pay some attention to the new window, 
> especially since it's placed immediately after the current one *and* 
> partially visible.

It doesn't have to be partially visible as long as you don't refer to 
the transparent overlay.

> > If you don't need to click the bubbles away, I think they are a 
> > good 
> > way of informative but unobtrusive way of getting information to 
> > the 
> > user. If there was such a popup, I think it would be nice to have a 
> > tray icon for all past events the user didn't acknowledge.
>       This is not critical information, so IMHO, the tray icon is not 
> needed. 
> It's not a disaster if user passed a window creation event.

Well, when we've already developed an unobtrusive messaging approach, 
why not reuse it for other messages of similar importance as well?
When I look at the computer monitor and just see this bubble window 
disappear without being able to identify it, I would like to be able to 
see what I missed.

> >>    Also, what happens when the focus window is maximized...?
> > The bubble could always be ontop, always at the same position. Of 
> > course, only if that very position is not the hot spot of current 
> > user 
> > input (ie. the view having focus is covered).
>       Now, this may be a good case for a bubble but I still don't like 
> it.
>       A solution which was suggested by a colleague at work:
>     The Deskbar entry(application) for that window flashes. But the 
> Deskbar is not visible you'd say. That's not a problem, bring the 
> Deskbar in front(without focus) for 3 seconds, then send it at its 
> previous place. We can even make the Deskbar 50/40% transparent.
>       I thought this is good idea, what do you think?

I think it's not necessary and also confusing to have two different 
transparent windows, one of them even flashing. 
I also dislike the blinking effect for its very nature :)

Anyway, I think the transparent window overlay is a good idea, and I 
also think that we agree on this to a certain extend. Anything beyond 
that we should continue to discuss.
I would like to have an unobtrusive messaging system, be it bubbles or 
something else, but it would be great if we could use this for other 
thing that just this one sense as well.

Bye,
   Axel.


Other related posts: