On Tue, Mar 27, 2007 at 07:27:25PM +0100, Alan Horkan wrote:
On Mon, 26 Mar 2007, Bryce Harrington wrote:
Well, like I think I said, I suspect the ideal approach would be for the primary nagivation to be in-canvas. So instead of just seeing the outline of a single page when you pull up Inkscape, you'd see several adjacent page outlines, and would simply pan or scroll around to see the other pages.
Laser printers can print very close to the edge of a page, home inkjet printers dont even come close. The concept of page can get a bit weird and surprising for users, and most people end up wasting a bunch of paper.
Obviously this is just another reason why distinguishing between "page" and "paper" is important. With enough generality and flexibility, I could specify my pages are 7.5"x10" (printable), while using 8.5"x11" paper. My canvas would then be composed of several 7.5"x10" rectangles side by side. It would be left to me to trim paper edges to compensate.
In an ideal amount of generality, the user could choose to see both page and paper boundaries. Perhaps they are making a comic and wish to balance the margin areas against the space between comic panes or something.
However all of this is just one speculation, until someone codes. Point is, doing the page management in-canvas opens a lot of potential and flexibility that wouldn't be as easily achieved as if it were done through UI widgetry. (much as I like UI widgetry)
Maybe part of my difficulty with this is the existing page concept in inskape on on hand has a sort of infinite canvas and then only part of that is intended as a printable page. There is was a trick/habit in Macromedia flash to use the off page areas as kind of a scap area (and it is a habit I think inkscape users might be taking advantage of) but when you go and put individual pages right beside each other that work habit is not an option.
Sure it is. Your scrap area is just that area not currently defined by any page boundaries.
Users however (as can be seen from bug reports) are certainly expecting the different kinds of layouts you speak of, some of which could be handled simply by better print control fitting the drawing to the desired pages, not necessarily needing to setup all that information in program in advance.
Right. Also, notice the number of requests for printing at Kinko's or other such print shops. A very poor way to solve the inkjet/laserjet issue you mentioned earlier would be to automatically detect and set up page and paper sizes based on the attached printer; if the document is prepared and tested on a machine with an inkjet and then taken to a place with a laserjet, the user could be very unhappy. I'm not sure what the best solution to this particular workflow is, but the more flexibility built into the program, the better. I would worry based on how this works in other programs that an automatic UI widget based would increase the chance of lousing up this particular usage model. At least with the in-cavas approach, if the user is able to view both page and paper boundaries, then hopefully it would be more visually evident what's going on.
IIRC, one of Jon Cruz' salient points is that window management (and, as a consequence, document workflow management) is something we ought to expect the _window manager_ to be solving.
Except unfortunately we have windows users, and to a lesser extent Mac and Gnome users who aren't going to be tweaking things much eathier so applicatoins cannot abdicate responsibility much as we might like to.
Not sure what your point here is. It's not a matter of tweaking. My out-of-the-box Ubuntu Feisty GNOME system automatically groups windows. I don't use Macs, but I understand they also have good window grouping/management out of the box.
Also note I said "expect" rather than "rely on". Admittedly there are LCD users and inferior windowing systems that don't meet this. But we should not fall into the trap of designing for the LCD and ending up crippling those on good systems. When you design for imaginary LCD users, you run the risk of optimizing the program for users that don't actually exist.
So best I think we can do is make things as generic and flexible as possible, and enable as many different workflows as possible.
... which without enough restraint gives us an airplane cockpit user interface with a baffling number of choices. Realistically though I'd guess Inkscape to err more on the side of providing the option (like KDE) than leaving it out so users dont get confused or shoot themselves in the foot (the Gnome approach, which I think anyone doing tech support will thank you for, not yet a huge contstrain of inkscape but we have a fair few Frequently Asked Questions).
My girlfriend is a 5th grade teacher and several of her students have picked up Inkscape. I once talked to her about a simplified Inkscape that would be more accessible for children. But she was emphatic that 5th graders are quite capable of learning adult tools, they just need time to learn and experiment. They're not cowards and they won't be scared by a powerful UI.
The things that are important for neophyte users are the same things that are important to any user: That the program is rock solid stable, well documented, has a well-thought-out UI that doesn't get in your way, and can be used for a large variety of tasks.
Further, as I've pointed out before, our principle userbase is not neophytes or the occasional user, but rather the heavy/power users who are likely to become contributors. Where neophytes and occasional users are important is that every heavy/power Inkscape user starts off as one of those. We don't need to dumb down the interface or disable a lot of flexibility for neophytes; we just need to avoid scaring them off right away, give them a good experience, and pack enough generality and power that they can grow with the program. We're going after the Visio/Illustrator crowd, not the MS Paint crowd.
A comment from just a few minutes ago on IRC:
What happens is, the inside of the line is filled. What I am drawing freehand, say, is a circle. So, I end up with wha looks like a donut oh, crap. I am wrong. Stupid me; ignore me. I was forgetting to join the endnodes sorry :/ this program is effing BRILLIANT
A little confusion at first, but a lot of love moments later. ;-)
Bryce