PTGUI features and enhancements notes
Roger Howard
observing more closely PTGUI 6 on the Mac (and in general). I took some
notes about features and functionality - I apologize if this isn't
formal enough, but if there is anything here you wonder about, or would
like more information about, please let me know.
I'd love to see PTGUI improve even more - right now it's a killer app,
but the UI could use some work (IMHO - no offense meant!) and this is
just my stream-of-consciousness notes on using PTGUI.
--------
UI
- Clean up menu bar
--- Move Pano Editor menu into Pano Editor window, or make it only
appear in the menu bar when the Pano Editor is front.
--- Remove Utilities menu as it contains only a single item
- File column in Source Images tab starts too narrow - especially when
window is large and there's plenty of room for this column to be much
wider. In fact, since it's the only one of the columns in this view
that has content whose length isn't predictable, make this column
auto-expand to fill all available width in the window (minus the other,
fixed-width columns)
- Clean up button hints (hover text).
-- Consider different text in Simple versus Advanced mode
-- Keep text short and specific; use common, technical terms to allow
users to seek help more easily. Using longer, less technical
descriptions is unhelpful as it shields the user from the knowledge
they need to learn the process.
-- If there is help hints, they should be on ALL buttons or on none.
I'm happy to help write this text if you're interested (and I'm sure
there are plenty of people able to help translate to other languages).
--- Align Images button text can/should be much shorter. "Automatically
generate control points and optimize".
-In Project Assistant, Source Images, and Image Parameters, make
thumbnails resizable (up and down) to allow a user to best maximize use
of screen space.
- I've never understood why Project Assistant and Source Image panels
shouldn't be merged into one
- In Image Parameters, allow import/export of parameters via copy/paste
or file import/export of tab-delimited data
- In Source Images, allow reordering of rows via drag/drop
- In Source Images, allow sort of rows based on EXIF creation date
- Provide a button or menu item to launch Batch Stitcher without a
project file (so project files may be manually added to it without
having to open the project file in PTGUI and then click Send to Batch
Stitcher)
- Option to specify default Optimizer, Blender. I'm getting much better
results optimizing with PanoTools than with PTGUI, so it's a pain to
keep having to reselect this option for each project.
- Open and Save dialogs should follow Mac OSX conventions. Default
option should be highlight and get default focus. Buttons should be
selectable by keyboard shortcut (cmd and the first letter of the
button... cmd-D for Don't Save, cmd-S for Save...
- Provide Autosave option for periodic saves or backups of open project
files
- UI should be as keyboard navigable as possible on OSX. Right now, my
habits learned from using the PC version are making the Mac version
feel far less efficient as I have to use the mouse to select more
options. For instance, I normally use tab and arrow keys to setup the
Output panel options - this doesn't work on OSX. Same with dialogs like
the File Format Settings dialog
- For that matter, get rid of the File Format Settings dialog, and
integrate these settings into the Output panel where they should be!
- On Create Panorama tab, the Create Panorama button looks like it has
focus even when it doesn't. Make sure focus is consistent and buttons
and other elements always display the right visual state for the
current focus state.
- Make sure scrolling regions have focus when it makes sense - in most
cases, scrolling regions should respond to pgup/pgdwn and arrow keys no
matter what other element has focus in a given window panel.
- TIFF ZIP compression
- When I click the Control Point Table from the toolbar, I generally am
looking for a global view of the control points table, so I'd prefer it
if the scroll defaults to the top - right now it is defaulting to
scroll to the selected control point, which makes sense when clicking
the Control Point Table button in the Control Points panel. By
defautling to scrolling to the top, this makes it easier to get to work
cleaning up the control points.
- Provide option to copy image metadata from source image file (perhaps
from the first file in the project) to the output file. Should include
all relevant metadata. May best be done by integration with ExifTool -
I do this now as part of my post-processing of output files.
- Provide a hook to run a post-stitching script - call a shell/batch
script, passing it path to the project file. This would allow the above
feature to be easily added (or enhanced).
- AppleScript support? Even just a simple method for calling the Batch
Stitcher (is there a method for doing this from the command line on
OSX?)
- Customizable toolbar - this is standard on OSX applications which use
a toolbar
- Separate binary for batch stitcher - OSX does not, in general,
support multiple instances of a GUI application, so having the same
binary appear multiple times in the dock and process views is strange
and un-Mac-like
- Use of Mac OSX conventions for menu item placement
Generally speaking, PTGUI is an awesome tool. It's powerful for sure,
and produces unmatchable results. At some point I'd like to see a major
focus of your development become the UI itself, as the core technology
seems to be incredibly powerful and complete by now. I have lots of
ideas for real interface overhaul, rather than simply individually
patching the problems I list above. A few pointers in general - get rid
of the tabbed panels, it creates an unnecessary division in the app
functionality, and I spend far too much time clicking between tabs -
this isn't Firefox! Look at how Adobe, Apple and Macromedia (and
Microsoft, for that matter) handle organizing their apps which have far
more features. An app can be rich, technical and sophisticated and
still be pleasing to look at, cleanly organized and layed out.
PTGui Support
Thanks for your comments, they are definately useful. I agree that there
are many things that can be improved in the user interface. At the same
time i'm hesitant to change anything, since each change will confuse or
even upset existing users. When 6.0 is released, I'm expecting tens of
questions 'where have the Set/Clear All buttons gone?' even though it
will be documented in the release notes..
> -In Project Assistant, Source Images, and Image Parameters, make
> thumbnails resizable (up and down) to allow a user to best maximize use
> of screen space.
This is possible already, you can resize the thumbnails in the Image
Parameters / Source images table by resizing the rows/columns. For
performance reasons all source thumbnails have the same size.
> - Provide a button or menu item to launch Batch Stitcher without a
> project file (so project files may be manually added to it without
> having to open the project file in PTGUI and then click Send to Batch
> Stitcher)
You can do this from the Tools menu.
> - UI should be as keyboard navigable as possible on OSX. Right now, my
> habits learned from using the PC version are making the Mac version
> feel far less efficient as I have to use the mouse to select more
> options. For instance, I normally use tab and arrow keys to setup the
> Output panel options - this doesn't work on OSX. Same with dialogs like
> the File Format Settings dialog
It seems to be impossible to change a checkbox in OSX using only the
keyboard. In Windows you can tab to it and press the spacebar, but on
the mac it seems that a checkbox never gets the keyboard focus. I'm
quite new to Mac so I may be missing something here?
Joost
Ian Wood
On 29 Aug 2006, at 14:44, PTGui Support wrote:
>> - UI should be as keyboard navigable as possible on OSX. Right
>> now, my
>> habits learned from using the PC version are making the Mac version
>> feel far less efficient as I have to use the mouse to select more
>> options. For instance, I normally use tab and arrow keys to setup the
>> Output panel options - this doesn't work on OSX. Same with dialogs
>> like
>> the File Format Settings dialog
>
> It seems to be impossible to change a checkbox in OSX using only the
> keyboard. In Windows you can tab to it and press the spacebar, but on
> the mac it seems that a checkbox never gets the keyboard focus. I'm
> quite new to Mac so I may be missing something here?
>
> Joost
Yes, this is one of the biggest UI differences between Windows and Mac.
By default on Mac OS, checkboxes can only be altered by mouse-clicks,
unless the user goes into the Keyboard & Mouse pane (Keyboard
Shortcuts tab) in System Preferences and turns on 'full keyboard
access'. Normally, keyboard access would only access text boxes and
lists.
On a similar subject, closing PTGui with an unsaved project on OS X
10.4 brings up a non-standard dialog box - normally 'save' would be
the default button and hitting Command-D would trigger 'Don't Save'.
The current box just has three buttons, no default button and doesn't
respond to the standard shortcuts.
Ian
Are Flagan
> At the same
> time i'm hesitant to change anything, since each change will
> confuse or
> even upset existing users.
All IMO:
The common problem with the apps coming out of PT is that they are
linearly organized according to the steps of the workflow. In other
words, they are basically set up as a tutorial, performed again and
again and again. While this may lower the threshold for new users, it
does not take into account what may be the most effective way of
organizing the information for experienced users who already have an
overview of the entire process. Rethinking the UI may upset some, but
probably not existing users.
Roger Howard
On Aug 29, 2006, at 6:44 AM, PTGui Support wrote:
>
> Hi Roger,
>
> Thanks for your comments, they are definately useful. I agree that
> there
> are many things that can be improved in the user interface. At the
> same
> time i'm hesitant to change anything, since each change will
> confuse or
> even upset existing users. When 6.0 is released, I'm expecting tens of
> questions 'where have the Set/Clear All buttons gone?' even though it
> will be documented in the release notes..
Agreed, but right now it's an incremental set of changes... I think
there's room for a major overhaul - I don't think that the basic,
common UI paradigm that PTGUI, PTMac, and Hugin all share is
necessarily optimal.
But again, it does work, and well enough that even a better designed
UI is not absolutely critical; but it would be nice, and I think it
would enhance the appeal for new users. I can't tell you how many
novices tell me they think Stitcher is the better app, just based on
first impressions... after using both there's almost always a change
in opinion of course!
>> -In Project Assistant, Source Images, and Image Parameters, make
>> thumbnails resizable (up and down) to allow a user to best
>> maximize use
>> of screen space.
>
> This is possible already, you can resize the thumbnails in the Image
> Parameters / Source images table by resizing the rows/columns. For
> performance reasons all source thumbnails have the same size.
Awesome!
>> - Provide a button or menu item to launch Batch Stitcher without a
>> project file (so project files may be manually added to it without
>> having to open the project file in PTGUI and then click Send to Batch
>> Stitcher)
>
> You can do this from the Tools menu.
Awesome!
>> - UI should be as keyboard navigable as possible on OSX. Right
>> now, my
>> habits learned from using the PC version are making the Mac version
>> feel far less efficient as I have to use the mouse to select more
>> options. For instance, I normally use tab and arrow keys to setup the
>> Output panel options - this doesn't work on OSX. Same with dialogs
>> like
>> the File Format Settings dialog
>
> It seems to be impossible to change a checkbox in OSX using only the
> keyboard. In Windows you can tab to it and press the spacebar, but on
> the mac it seems that a checkbox never gets the keyboard focus. I'm
> quite new to Mac so I may be missing something here?
Actually if you turn on Access for Assistive Devices and full access
to controls for keyboard control almost all apps can be fully
controlled from the kbd, including access to checkboxes, menus, etc.
But whatever GUI toolkit you're using must not be Universal Access-
capable as the controls don't respond to kbd control at all.
I almost always have this on as I feel it's a much more efficient way
to interact with the GUI; it also enables the GUI to be scripted via
AppleScript.
Yeah, out of the box Mac OSX doesn't have this *on* - but it is fully
implemented in most apps, and just needs to be turned on. Check it
out :)
-R
PTGui Support
>
> On Aug 29, 2006, at 6:44 AM, PTGui Support wrote:
>
>> Hi Roger,
>>
>> Thanks for your comments, they are definately useful. I agree that
>> there
>> are many things that can be improved in the user interface. At the
>> same
>> time i'm hesitant to change anything, since each change will
>> confuse or
>> even upset existing users. When 6.0 is released, I'm expecting tens of
>> questions 'where have the Set/Clear All buttons gone?' even though it
>> will be documented in the release notes..
>
> Agreed, but right now it's an incremental set of changes... I think
> there's room for a major overhaul - I don't think that the basic,
> common UI paradigm that PTGUI, PTMac, and Hugin all share is
> necessarily optimal.
Perhaps not. On the other hand, I think there's a reason for the fact
that they share the same workflow, they didn't just copy that from
PTGui, right?
The problem is that a project contains a lot of parameters which should
be accessible somehow. They could be organized in separate dialog boxes
(but that would block the user interface until OK is pressed), floating
windows (but this can get messy). So I think the tabs are a clean way of
organizing many parameters in quickly accessible way. Although the way
the parameters are organized in tabs could perhaps be improved.
A good improvement might be to allow the tabs to be 'undocked' into
separate floating windows (more or less Michel's suggestion).
When comparing with other applications (e.g. Stitcher), keep in mind
that they hide many of the parameters from the user.
But I'm open for suggestions (although 6.0 really needs to be finished
first..). How would you reorganize the user interface?
Joost
PTGui Support
> By default on Mac OS, checkboxes can only be altered by mouse-clicks,
> unless the user goes into the Keyboard & Mouse pane (Keyboard
> Shortcuts tab) in System Preferences and turns on 'full keyboard
> access'. Normally, keyboard access would only access text boxes and
> lists.
Aha! Unfortunately the GUI toolkit (wxWidgets) of PTGui doesn't support
this at this moment.
PTGui Support
> All IMO:
>
> The common problem with the apps coming out of PT is that they are
> linearly organized according to the steps of the workflow. In other
> words, they are basically set up as a tutorial, performed again and
> again and again.
I disagree. If PTGui were a wizard (with Previous/Next buttons) then
yes, this would force the user into a specific workflow. But the current
tabs are just a way of organizing parameters and they can be accessed in
a random way.
Of course I don't mean the Project Assistant, which should guide users
through the process.
Joost
Are Flagan
> I disagree. If PTGui were a wizard (with Previous/Next buttons) then
> yes, this would force the user into a specific workflow. But the
> current
> tabs are just a way of organizing parameters and they can be
> accessed in
> a random way.
You are missing the point. Force was not the issue, nor was it
mentioned.
The problem is not that you can't open the book on a random page, but
that the linear narrative paradigm persists in the organization of
the entire volume and that some pages even have big wasteful spaces,
and little else, as a result.
Have a look at how Adobe have done ACR and, later, Lightroom. How do
they differ from PTGui? How have they approached the separation of
structure and presentation, parameters and views? By floating the
tabbed parameter "pages" onto the desktop and thus presenting the
same old bookish paradigm as a ream thrown into the air, as you
speculate? By going automagically WYSIWYG, like Stitcher and Calico,
to target the market for picture books instead?
Some seasoned developer once said that, given the choice, he would
always opt for an innovative UI over good code. His reasoning was
that fixing and improving the underlying code to a fantastic UI, most
effectively translating and accessing the core idea and function of
the app, was much easier over time than trying to make the app better
by adding new algorithms to a mashup of UI elements. This seemed
backward to me at the time, on the surface putting form over
function, but I have since realized that he was likely right.
Consequently, if the upgrade path for PTGui for Mac actually rests
with this legacy Windows-ported UI, not the shifting SIFT flavor, how
would or should that influence a purchasing decision? UI design is
arguably not "just" a way of organizing parameters, as you suggest.
It really matters beyond appearances.
PTGui Support
> On Aug 29, 2006, at 5:52 PM, PTGui Support wrote:
>
>> I disagree. If PTGui were a wizard (with Previous/Next buttons) then
>> yes, this would force the user into a specific workflow. But the
>> current
>> tabs are just a way of organizing parameters and they can be
>> accessed in
>> a random way.
>
> You are missing the point. Force was not the issue, nor was it
> mentioned.
>
> The problem is not that you can't open the book on a random page, but
> that the linear narrative paradigm persists in the organization of
> the entire volume and that some pages even have big wasteful spaces,
> and little else, as a result.
I agree with you on the wasted space. As I said the contents of the tabs
could be organized better. Create Panorama and Panorama Settings could
be merged for example.
But the parameters must somehow be organized into groups, because it's
too much to present in a single screen. And yes, the groups are in
workflow order, but is that a problem?
> Have a look at how Adobe have done ACR and, later, Lightroom. How do
> they differ from PTGui? How have they approached the separation of
> structure and presentation, parameters and views? By floating the
> tabbed parameter "pages" onto the desktop and thus presenting the
> same old bookish paradigm as a ream thrown into the air, as you
> speculate? By going automagically WYSIWYG, like Stitcher and Calico,
> to target the market for picture books instead?
Haven't looked at Lightroom. But in ACR, I also see a set of tabbed
pages with parameters ('Adjust', 'Detail', 'Lens', etc). And an image
area showing the result. Now think that image into a separate window
(like the panorama editor), and you have exactly the same UI structure
as PTGui.
> Some seasoned developer once said that, given the choice, he would
> always opt for an innovative UI over good code. His reasoning was
> that fixing and improving the underlying code to a fantastic UI, most
> effectively translating and accessing the core idea and function of
> the app, was much easier over time than trying to make the app better
> by adding new algorithms to a mashup of UI elements. This seemed
> backward to me at the time, on the surface putting form over
> function, but I have since realized that he was likely right.
>
> Consequently, if the upgrade path for PTGui for Mac actually rests
> with this legacy Windows-ported UI, not the shifting SIFT flavor, how
> would or should that influence a purchasing decision? UI design is
> arguably not "just" a way of organizing parameters, as you suggest.
> It really matters beyond appearances.
I agree. Of course! A good user interface is extremely important.
You may argue that the UI doesn't yet look Mac native. The tabs were
indeed copied from the Windows user interface (because the Mac tab
control cannot occupy more than a few pages). And you'll still see a few
windows-style checkboxes.
But look through that and tell me: what is wrong with the structure of
the user interface? And more important, how can it be improved?
Forgive me if I'm missing your point. But I'm interested in your ideas,
not just in hearing what is wrong.
Joost
Are Flagan
>
> Are Flagan wrote:
>> On Aug 29, 2006, at 5:52 PM, PTGui Support wrote:
>>
>>> I disagree. If PTGui were a wizard (with Previous/Next buttons) then
>>> yes, this would force the user into a specific workflow. But the
>>> current
>>> tabs are just a way of organizing parameters and they can be
>>> accessed in
>>> a random way.
>>
>> You are missing the point. Force was not the issue, nor was it
>> mentioned.
>>
>> The problem is not that you can't open the book on a random page, but
>> that the linear narrative paradigm persists in the organization of
>> the entire volume and that some pages even have big wasteful spaces,
>> and little else, as a result.
>
> I agree with you on the wasted space. As I said the contents of the
> tabs
> could be organized better. Create Panorama and Panorama Settings could
> be merged for example.
Yes, the Panorama Setting is a grand vista of empty space.
>
> But the parameters must somehow be organized into groups, because it's
> too much to present in a single screen. And yes, the groups are in
> workflow order, but is that a problem?
Are we looking for a solution without a problem? In a way, of course,
since people actually make panos with PTGui. The groupings of the
parameters are relational and that fundamentally makes sense. The
question is, then: What is this workflow, or, perhaps, what are these
workflows?
>
>> Have a look at how Adobe have done ACR and, later, Lightroom. How do
>> they differ from PTGui? How have they approached the separation of
>> structure and presentation, parameters and views? By floating the
>> tabbed parameter "pages" onto the desktop and thus presenting the
>> same old bookish paradigm as a ream thrown into the air, as you
>> speculate? By going automagically WYSIWYG, like Stitcher and Calico,
>> to target the market for picture books instead?
>
> Haven't looked at Lightroom. But in ACR, I also see a set of tabbed
> pages with parameters ('Adjust', 'Detail', 'Lens', etc). And an image
> area showing the result. Now think that image into a separate window
> (like the panorama editor), and you have exactly the same UI structure
> as PTGui.
It's the same, in the sense that both recognize that a GUI differs
from the command line in the graphical feedback provided upon
commands entered. The ongoing quest is to make this not only easily
comparative, by putting fields, buttons and sliders next to the
visual update (to always also see the results of your choices), but
near instantaneous even for incredibly intensive operations, as
evidenced by, for example, the CoreXXX influx. Taking this into
account, how well does PTGui do in relation to the layout of ACR and
Lightroom? I think Ed Tufte has played a part here and influenced
Adobe's UI designers to dock their palettes more and more compactly
into a dashboard analogy. All your tweaks and instruments are there,
right in front of you, and your static windscreen keeps updating the
journey of the workflow.
>
>> Some seasoned developer once said that, given the choice, he would
>> always opt for an innovative UI over good code. His reasoning was
>> that fixing and improving the underlying code to a fantastic UI, most
>> effectively translating and accessing the core idea and function of
>> the app, was much easier over time than trying to make the app better
>> by adding new algorithms to a mashup of UI elements. This seemed
>> backward to me at the time, on the surface putting form over
>> function, but I have since realized that he was likely right.
>>
>> Consequently, if the upgrade path for PTGui for Mac actually rests
>> with this legacy Windows-ported UI, not the shifting SIFT flavor, how
>> would or should that influence a purchasing decision? UI design is
>> arguably not "just" a way of organizing parameters, as you suggest.
>> It really matters beyond appearances.
>
> I agree. Of course! A good user interface is extremely important.
>
> You may argue that the UI doesn't yet look Mac native. The tabs were
> indeed copied from the Windows user interface (because the Mac tab
> control cannot occupy more than a few pages). And you'll still see
> a few
> windows-style checkboxes.
>
> But look through that and tell me: what is wrong with the structure of
> the user interface? And more important, how can it be improved?
I think this depends on the limits and possibilities of the chosen
development framework. Fundamentally and generally, I would have
attempted to split the views from the parameters and kept both
present at all times. As it is, views and parameters, with the
exception of the pop, follow the tabular order and thus remain
exclusive to their place in the workflow narrative. On first
impressions, this story may have a pedagogical benefit, but I wonder
if this compartmentalization is also damaging in that it prevents a
better relational overview, both visually and settings wise, of the
process underway. Where is the updated summary? The panorama editor
is imo gold here. Not because it allows for hands-on editing devoid
of those silly numbers, but precisely because it summarizes the
settings employed in a neat way. What if your source images were
loaded directly into horizontal thumbnails in such a PE viewport?
What if your application of yaw pitch and roll was directly applied
to the same arrangement? What if lens and panorama settings warped it
and set the layout? If you consider it, along with the CPU cycles
consumed, what are the benefits of vertically listing thumbnails for
a pano? If you skipped them, how much could those adjacent parameters
be compressed into list views of values and attributes? Source images
on 6 or 8 lines? Imagine, then, having your interchangeable PE/Crop/
CP in one toggled viewport and a setable list of all properties, many
if not most available at a glance, running down/along a dedicated
column/row. It's starting to resemble ACR and Lightroom, of course.
And Aperture. What these newer apps have all realized in my view is
that UI design is not about framing the picture, the fabulous brushed
metal phase at Apple, or writing that epic manual through the UI, but
about providing information, both input and output, succinctly. In
other words, making your numbers smaller and your views bigger.