[openbeos] Re: inconsistency?
- From: Adi Oanca <adioanca@xxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Thu, 23 Sep 2004 10:15:09 +0000
Axel Dörfler wrote:
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.
Um... suposedly you are talking about more windows poping out while we are busy with the focused
window...
I don't see the difference. Each new window is placed based on best fit algorithm. When no more
desktop area is visible(because new_windows covered it), new windows will be placed above old
new_windows. (the cycle "somehow"(because is best-fit) repeats itself)
You see... no difference.
I prefer to find things where I left them,
Your things will be where you left them.
Only new windows are placed following a pattern(cascade, best-fit, edge)
and I am annoyed if
windows pop up at a place where I didn't expect it.
Of course.
Where would you expect it? Behing the focus window, totally covered? Sorry, I don't like that,
especialy since it's a missed window.
Fixed layout sucks. Big time.
Now, when you talk about opening a new StyledEdit window (the second),
there is definitely a need for proper placement.
See...
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.
Yes, I agree too.
Still, some can be done in R1. (#1 & (#2 | your_bubbles))
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.
Axel, this is obtrusive. The user needs not to be disturbed! He just needs to be signaled, so he
would know about this new window. I'm not sure anymore that the transparency effect is a good idea.
The user would get distracted by the more than obvious signal.
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.
No, again :-). He has to finish the small task he's doing. After that he may *or* may not pay
attention to the new window. As I already said: this is not a critical event.
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.
Yes, ctrl-tab will be in place for that as we already decided the new window will be placed
immediately after the current one.
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.
What would you see in a 1 - 1,5 sec decreasing transparency effect? Not
very much.
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.
You are complicating things. (in case you're using bubbles)
If you take the flashing/highlighting Deskbar/border effect you won't need that tray icon anymore.
Also this would be more visible than your tray icon.
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.
Only a transparent deskbar with an entry flashing/highlighted.
I also dislike the blinking effect for its very nature :)
Yes, me too. Hate WinXP for that. KDE does so much better - only 2 flashes and then the Deskbar
entry is just highlighted.
Anyway, I think the transparent window overlay is a good idea, and I
also think that we agree on this to a certain extend.
:-) Not anymore.
Anything beyond
that we should continue to discuss.
Looks like we totally disagree.
So, what do we do now? Should we just trow away all our energy that we've put in this thread?
Maybe someone offers to do a flash mockup for the 2 ideas, so that we could see which one feels
better. :-)
Adi.
- References:
- [openbeos] Re: inconsistency?
- From: Axel Dörfler
Other related posts:
- » [openbeos] inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
- » [openbeos] Re: inconsistency?
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.
Your things will be where you left them. Only new windows are placed following a pattern(cascade, best-fit, edge)
See...
Yes, I agree too. Still, some can be done in R1. (#1 & (#2 | your_bubbles))
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.
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.
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.
What would you see in a 1 - 1,5 sec decreasing transparency effect? Not very much.
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.
Only a transparent deskbar with an entry flashing/highlighted.
:-) Not anymore.
Looks like we totally disagree.
Adi.
- [openbeos] Re: inconsistency?
- From: Axel Dörfler