Broken Layout
Yuval Levy
'broken' by the introduction of the new dragging functionality, I looked
deeper into the matter. Turn out it was not broken, it was 'just' hidden
outside of the viewport.
While I normally work in full screen mode and am not aware of these issues, I
have taken the steps of resizing all windows to their minimum size and trying
to access app functionality. My conclusions:
THE CURRENT LAYOUT OF HUGIN IS 'BROKEN'.
We need decisions and consistency about the user interface layout.
Here is what I would suggest:
1. Decide a minimum screen size at which the application is functional.
2. Decide a consistent way of paging the information that can't be fit in such
minimum screen size - can be vertical scrolling, can be sub-tabbing, can be
anything else we have not seen or tried yet.
3. Document the above decisions and enact them as project policies.
4. Implement the above decisions consistently across windows and tabs.
Given the current hardware trends, I would suggest:
1. 800x480 minimum screen size
2. vertical scrolling within the tab (not so cool for mouse users, but look at
tablets)
Comments?
Can we do this in the yet to be started 2011.0 release cycle, or do we have to
ship another version of Hugin that becomes unaccessible at screen sizes below
1366x768?
Yuv
T. Modes
>
> THE CURRENT LAYOUT OF HUGIN IS 'BROKEN'.
>
minimum window size.
> Can we do this in the yet to be started 2011.0 release cycle, or do we have to
> ship another version of Hugin that becomes unaccessible at screen sizes below
> 1366x768?
800x600 screen size. So please not soo general statements.
> Given the current hardware trends, I would suggest:
> 1. 800x480 minimum screen size
seems to be related to Asus eeePC users.
Thomas
Jan Martin
Why can't one enter the numeric value and then just press "Enter" on the keyboard?
Right now one has to press the button using the mouse.
Thanks,
Jan
(on Ubuntu Linux)
--
You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
--
http://www.DIY-streetview.org
Rogier Wolff
> 1. 800x480 minimum screen size
I'd go one bigger (1024x600). We can demand that users have a
reasonable screen when working with a graphical application.
It should work "smoothly" at 1024x600, and be usable (i.e. no buttons
permanently out of view) at even lower resolutions. (e.g. having to
work with a window larger than the screensize and moving the window
around counts as unusable)
Roger.
--
** R.E....@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
Yuval Levy
> On Sat, Feb 26, 2011 at 09:04:53AM -0500, Yuval Levy wrote:
> > 1. 800x480 minimum screen size
>
> I'd go one bigger (1024x600).
No. I want to use it on a 1GHz ARM Android without having to buy an expensive
high resolution or large display. There are plenty of such devices on the
market and more are coming, faster and better, with the same screen size of
800x480.
> We can demand that users have a
> reasonable screen when working with a graphical application.
We can demand plenty of things but we can support more. This is not pixel
detailed photo editing. This is not for your gigapixel panoramas. This is
stitching. I want a traveler to be able to point a Galaxy S cell phone around
a couple of times and stitch a few pics on the spot to share right away via
flickr. The more complex work can be saved for later, at home, on dual screen
workstations.
> It should work "smoothly" at 1024x600, and be usable (i.e. no buttons
> permanently out of view) at even lower resolutions. (e.g. having to
> work with a window larger than the screensize and moving the window
> around counts as unusable)
now you are absolutely inconsistent with your previous statement. Either it
works at lower "resolutions" or it does not. And indeed you are right that
moving the window around counts as unusable.
We can make elements dockable and floatable; or we can make individual windows
scrollable (in one direction only, carefully designed to be consistent and
understandable); or we can split into even more tabs; but the mix and match we
have now is just confusing and when elements are out of sight they are also
out of mind because of this lacking indication of where the page continues.
Yuv
Rogier Wolff
On Mon, Feb 28, 2011 at 07:56:19AM -0500, Yuval Levy wrote:
> > We can demand that users have a
> > reasonable screen when working with a graphical application.
> We can demand plenty of things but we can support more. This is not
> pixel detailed photo editing. This is not for your gigapixel
> panoramas. This is stitching. I want a traveler to be able to
> point a Galaxy S cell phone around a couple of times and stitch a
> few pics on the spot to share right away via flickr. The more
> complex work can be saved for later, at home, on dual screen
> workstations.
OK. Different usage model/mode. Agreed, you've got me convinced.
> > It should work "smoothly" at 1024x600, and be usable (i.e. no buttons
> > permanently out of view) at even lower resolutions. (e.g. having to
> > work with a window larger than the screensize and moving the window
> > around counts as unusable)
> now you are absolutely inconsistent with your previous statement.
> Either it works at lower "resolutions" or it does not. And indeed
> you are right that moving the window around counts as unusable.
Back in 2000 when I had my website designed, I emphasized that it
should work on 640x480, but that it should work smoothly on 800x600
and up.
That was a workable solution: Some (unimportant) data falls off the
side at 640x480, everything is in view at 800x600, and all
screen-realestate is used at higher resolutions. That's (IMHO) the
proper way to have things.
So... If seldomn used options are not visible by default, but
reachable by scrolling that makes the application usable, but maybe
not "smoothly". For the lowest resolutions (at or below the minimum)
that's acceptable.
So, with your current suggestion that we have a vertically scrolling
window if it doesn't fit on the screen: great. But possibly some tabs
need just over 800 pixels horizontally. So although the gui design
guideline says that it should be frowned upon, we might have a
horizontal scrollbar just for the lowest (or below the lowest)
resolution.
Jeffrey Martin
If I made a real attempt to redesign some elements of hugin, UI-wise i mean, would anyone be interested in trying to implement it? (If anyone agreed with the suggestions of course)
I think everyone can admit that Hugin looks like it was designed by engineers. Because, I guess, it was! :-) I'd like to help improve it visually.
kfj
On 28 Feb., 13:56, Yuval Levy <goo...@levy.ch> wrote:
> We can demand plenty of things but we can support more. This is not pixel
> detailed photo editing. This is not for your gigapixel panoramas. This is
> stitching. I want a traveler to be able to point a Galaxy S cell phone around
> a couple of times and stitch a few pics on the spot to share right away via
> flickr. The more complex work can be saved for later, at home, on dual screen
> workstations.
squashed some than having to scoll around on a large tidy space.
I'd like to add (and, please, don't call me a hippocrite - after all
I'm trying to get my python scripting interface into hugin ;-) that
some TLC spent on the UI and workflow might even produce more value
than yet another new feature.
Kay
Bruno Postle
Go ahead, I suggest starting with screenshots and moving things
around - There are lots of functions that are in the wrong places.
--
Bruno
Gnome Nomad
> On this note,
>
> If I made a real attempt to redesign some elements of hugin, UI-wise i
> mean, would anyone be interested in trying to implement it? (If anyone
> agreed with the suggestions of course)
>
> I think everyone can admit that Hugin looks like it was designed by
> engineers. Because, I guess, it was! :-)
And in usability terms, it does a great job for taking users through the
steps needed to create a panorama.
> I'd like to help improve it visually.
Hmm, I don't see anything broken about the UI. Eye candy for eye candy's
sake does not "improve" anything.
--
Gnome Nomad
gnome...@gmail.com
wandering the landscape of god
http://www.cafepress.com/otherend/
Carl von Einem
> Jeffrey Martin wrote:
>> On this note,
>>
>> If I made a real attempt to redesign some elements of hugin, UI-wise i
>> mean, would anyone be interested in trying to implement it? (If anyone
>> agreed with the suggestions of course)
>>
>> I think everyone can admit that Hugin looks like it was designed by
>> engineers. Because, I guess, it was! :-)
>
> And in usability terms, it does a great job for taking users through the
> steps needed to create a panorama.
This could be more or less correct for the more advanced users but I
also think there is still some room for improvement.
>> I'd like to help improve it visually.
>
> Hmm, I don't see anything broken about the UI. Eye candy for eye candy's
> sake does not "improve" anything.
I don't think Jeffrey wants to achieve eye candy here. You haven't seen
his self built pano head! ;-)
As an example why do important UI elements vanish if I switch the main
window into fullscreen mode?
Or why don't we have a thumbnail in the camera&lens tab? So I have to go
back to the images tab to identify one or more images. Since my
selection in this tab is not remembered in the other tab I have to make
notes of the respective image numbers so I can select them again.
In optimizer tab I can select or deselect a whole row only. Why can't I
click/hold and drag the mouse to select consecutive image numbers? Or
cmd-click non consecutive image numbers to select/deselect them? I'd
also love to see the file name as tooltip when hovering over an image
number.
Also in optimizer tab the rows for e.g. 'd' and 'e' could be exchanged
with 'universal' rows so I don't need to manually tweak the script to
optimize for something like 'g' or 't': this could be accomplished with
a drop down list of available parameters instead of the row title.
Carl
kfj
On 4 Mrz., 09:57, Carl von Einem <c...@einem.net> wrote:
>
> As an example why do important UI elements vanish if I switch the main
> window into fullscreen mode?
or, to add another thing that has always bugged me, sort columns when
the column header is clicked on - in every columnar display and not
just in some (I have the control points tab in mind here)
Kay
Jeffrey Martin
Clean UI != eye candy
designed by engineers != clean UI
clean UI != designed by engineers (usually)
Jeffrey Martin
It's a matter of what you mean by "everything". Hopefully it is "almost nothing" ;-)
Anyway, this is a bit of a silly conversation, I'll just try to make something.
kfj
On 4 Mrz., 10:35, Jeffrey Martin <360cit...@gmail.com> wrote:
> I agree with you Kay.
>
> It's a matter of what you mean by "everything". Hopefully it is "almost
> nothing" ;-)
processing options for nona end enXXXX.
And, as far as the 'engineer' discussion is concerned, how about
thinking along the terms of 'software engineering'? I think the
distictions made are artificial. There is good design and bad design,
there are good and bad engineers, software engineeers being no
exception. The discussion should be about quality and not about
professions.
Do, by all means, try and make something! But try to make it quite
something ;-)
Kay
Agos
1. Decide a minimum screen size at which the application is functional.
Jeffrey Martin
On Friday, March 4, 2011 11:04:50 AM UTC+1, kfj wrote:
Gnome Nomad
> http://www.cafepress.com/ otherend/ <http://www.cafepress.com/otherend/>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Hugin and other free panoramic software" group.
> A list of frequently asked questions is available at:
> http://wiki.panotools.org/Hugin_FAQ
> To post to this group, send email to hugi...@googlegroups.com
> To unsubscribe from this group, send email to
> hugin-ptx+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/hugin-ptx