Le lundi 29 octobre 2007 à 10:47 +0100, Adrian Custer a écrit :
> Emmanuel, again sorry for coming on so strong. The disappearing charts
> reminded me of the old days. You don't know this about me but I arrived
> into the Gnumeric project back in the days when computers were vaccum
> tubes and Guppi ruled the charting world (I'm thrilled to see a "Guppi"
> theme whatever that may mean). I spent a lot of time, back in the day,
> breaking trow's work in any way I could. So seeing a new area for users
> to prod the charts, I set at breaking things and was very surprised to
> see how easily I could make things difficult for everyone: users,
> documenters, bug reporters and coders. "my chart disappeared" is a
> puzzle kind of bug especially if the program is in a totally happy
> state.
What we really miss is a undo/redo that works also inside the graph
editor. I'll try to implement one, but it's too late for the next stable
version.
Meanwhile, I don't think the current situation is that terrible. It's
already possible to recover an item that was placed inadvertently
outside of the graph area, by either setting it's position via the
property dialog, or by canceling all the editor session changes.
> Yes, some data is much too big to handle on screen (say a year long time
> series with five data points per day 6:00/9/12/15/18:00). The most
> elegant thing for that would be to have the plot scale nicely from the
> smoothed full year view into the daily 'connect the dot' view with a
> horizontal scrollbar; but that's for tomorrow. The example is mostly to
> answer Andreas who wonders why users might not want the whole plot in
> the visible area. I used to make the guppi window the size of 20
> desktops and then slide the window back and forth to look at the shapes
> of different days in the different seasons---what Havoc calls a broken
> answer to a broken app.
>
> The configurable chart area is *awesome*, much more intuitive than the
> tree configuration system. This could grow to get a dynamic 'Add' area
> which shows, as widgets, the appropriate elements from the "Add" menu as
> each piece is selected in the configurable chart area; this could then
> become the primary interface.
The current implementation is relatively rough, and will take some times
before being really good. The idea of the 'add' area is interesting.
> We would have to offer the users their
> familiar basics as well such as cut/copy/paste. Actually, this occurs to
> me as something we want to do regarless; the drop down "Add" menu hides
> from users the potential of the chart widget.
>
> However, while the configurable chart area is very cool, it is also
> equivalently *hard*, a complex paradigm to build and offer users. I
> offer these two principles for that paradigm only to prod your thinking.
>
>
> Principle: In a 'visual editor,' all elements present must remain
> visible.
I'm not sure to agree with this principle, or even simply to know how to
achieve it. A user may position an object under another, may change it's
color and make it invisible. That's where the object tree is useful.
> This has consequences for the widget. I would make the "charting
> area" white to show the aspect ratio of the 'visible area'
> designated on the worksheet. This might be done with an alpha
> 10% grey mask over all the non-charting area.
I'm going to add a visual indication of the graph area.
> You may need to
> make the border around the visible area big enough to hold any
> piece you want to permit to leave charts out of the 'visible
> area' (say if you want to let users to have a 'scrap heap' on
> the side).
I agree we should see objects placed outside of the graph area.
> I would also block the charts from becoming too small, say
> smaller than makes the bottom right handle clearly identifiable
> as a handle. (10px wide or some such).
Good idea.
> I would prevent charts from "inverting" (in the worksheet, this
> is done by changing handle when the user drags the mouse
> diagonally back across the chart; since you have only one handle
> in your widget, I am not sure what you want to do).
>
> I would prevent charts from leaving the chart area or at least
> from leaving too far *but* would keep them visible regardless.
> You might want to prevent charts from moving more than 95% from
> the center to force them to stay 'worksheet visible' or from
> moving more than 110% percent from the center (i.e. not
> worksheet visible but still 'Configure Chart' visible) according
> to your desires *but* the user should still see the chart and be
> able to drag it back if needs be. To answer Andreas, I could
> imagine this would let us store alternative charts but only show
> one on the page that gets printed. I'm not sure I would do that,
> merely arguing that it's a reasonable idea.
>
> Principle: make the common needs easy at the expense of the uncommon
> ones.
With the following difficulty: what is common, and what is uncommon ?
> Since you now have the infrastructure to be totally crazy, you
> need to design the UI to help users do what they want. Right
> now, this UI feels like it was designed to make *everything*
> possible. That's fantastic. However, I suspect most users
> wanting to re-arrange their charts want to do simple things like
> flip charts from vertically stacked to horizontally, side by
> side. The first thing I tried, before I realized what you were
> letting me do, was to make the plot areas uneven by dragging the
> "bar" between the charts to make one bigger and the other
> smaller. So vertical <-> horizontal and uneven I suspect will be
> popular and should therefore be easy to do. Perhaps users may
> also frequently want to place one smaller chart on top of an
> other. But mostly, I wouldn't expect them to get too much
> crazier.
> Starting small, perhaps you start by making the charts only
> jointly resizable, not fully, independently re-sizable but
> merely able to shuffle around and exchange space. That may be
> more intuitive. You would then eventually have to add a special
> "place chart on top" UI workflow and 'visual' look.
The array like chart layout inside a graph is already implemented, but
changes are not persistent for now. That's why there's no UI for that.
This lead me to something I wonder. Currently, it's only possible to
move the objects freely. I've planed to add a secondary mode, where if a
modifier key is pressed, the object is moved by changing the "hint" of
the automatic position (for example, for a chart title, top, bottom,
left of right position). Perhaps it could be the primary moving mode ?
> Again these ideas are merely offered to prod you to reset your thinking
> from the coder's perspective to the user's perspective long enough to
> design a UI as great as the code that you have already written.
Do you really think we're coding a graphing framework including a visual
editor without thinking about the user ? We try our best to provides a
useful and usable tool for the gnumeric users. Things are far from
perfect, but are improving. Constructive criticisms, suggestions (like
what can be found in this email) or patches are welcomed.
Emmanuel.
_______________________________________________
gnumeric-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gnumeric-list
