Re: The state of the canvas

Alexander Larsson said...

In fact, I think its more important to have a simple canvas like that
than a really powerful flexible thing to be used for diagram editors and
powerpoint apps for the simple reason that I'm not at all sure such apps
would use a generic canvas. Each major app is gonna have some
requirement that makes them do their own canvas widget anyway. The
canvas is after all an extremely core part of an app like dia,
illustrator or powerpoint. The question is, is it possible to do a
canvas that caters to both usecases?
I think there's a compelling reason for multiple apps to use a common canvas, despite their 'custom' needs: accessibility. Getting canvas accessibility right is not trivial, and it makes sense to try and do it in one place, to the extent possible.

From your page its very obvious that your target for this design is Dia,
since you have things like selection and focus handling. This isn't bad
per-se, but its likely that apps may want slightly different behaviour
with such things, and maybe the core should just be powerful enough that
things like that can be implemented in a layer above it.
I think not - all canvasses need selection and focus handling for accessibility reasons. Even if the resulting content is "read only", selection and focus handling are important for blind users.

The "Details" section seems a bit weird to me. It sounds like the model
for that map canvas would be the full data for all of germany in every
detail, and the canvas would iterate over each street in germany
checking the details level for it. Thats not very scalable. In fact,
huge geographic datasets are a pretty special-case thing, and I'm sure
map apps do map-specific things to get good scalability that a general
canvas can't. So, the right thing to do here might be to just feed the
canvas a more limited set of items, based on the zoom level, etc?
That would work, perhaps, but I think general-purpose "zoom level" pruning would be a useful general feature nonetheless. I don't think it's specific to maps at all.

The distinction being made between "scale factor" and "zoom level" (for want of a better set of terms) is very important to accessibility - for instance, I may want a large print version of the map, without including more detail. So, taking "scale factor" to mean the relative size of onscreen objects, and "zoom level" to mean the viewport size relative to the original document, the text and label sizes would need to scale with the "scale factor" but not the "zoom level".

The "zoom level" concept also assists accessibility, since it gives explicit "importance" grouping to features.

One thing I really like about the proposal is that all the elements on the canvas are hierarchically grouped, and have associated text. I would hope that we would de-couple the "title" concept from the "name" concept however, since even objects without onscreen titles will need names of some sort, for accessibility reasons.

Keyboard navigation and keyboard access to the canvas is important, and I think doing it in the canvas widget itself, to the extent possible, will give better consistency and coverage.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]