Re: [libreoffice-design] Breaking out of the box (applications versus objects)

On Saturday 29 Jan 2011 10:15:13 Christoph Noack wrote:
> Hi Greg,
>
> although some others already replied, I'd like to start with a "fresh"
> reply :-)
>
> Am Freitag, den 28.01.2011, 00:44 +0000 schrieb noh.way.jose:
> > I'm new to this community, so please forgive me if the topic I'd like to
> > discuss has already been aired.
>
> So, a warm welcome to this community!
Thanks, Christoph and all who have taken the time to reply. It's great to see 
such a vibrant community. Reminds me of the Open Mapping community :o)
> [...]
>
> > Instead of applications, let's have a document, a variety of choices of
> > rendering the document (print, screen, presentation, web, edit,
> > collaborative edit, &c.) and tools. The tools can still be categorised,
> > but not as they are in applications, where the application is a hard
> > boundary. The tools here could all be used, irrespective of the
> > presentation mechanism. Categorisation of the tools need only be done as
> > a means to support user tasks, perhaps along multiple dimensions, using
> > tags. This proposal means only having to develop a tool once and
> > allowing the concurrent availability of tools that the artificial
> > applications boundaries would normally exclude. For example, DTP tools,
> > such as layout grids and text flow, which could be used alongside more
> > traditional word processing tools in documents, presentations and other
> > formats.
>
> Where to start? I read some deeper thoughts within your mails, but at
> the end the question is, who benefits in what way?
>
> Some thoughts:
>       * Marketing: StarOffice / OpenOffice.org has been made more
>         "single application like", since people demanded to have single
>         applications like Word, Excel, ... you still see many problems
>         where it is unclear whether we talk about "LibreOffic", or e.g.
>         "Writer". (By the way, something we have to decide on later). In
>         the past, there was just "StarOffice" and different document
>         types.
I guess you could consider my proposition as an extrapolation of one or both 
of: 
- OLE/COM/DCOM  in an application environment, where I always felt something 
approximating my proposition was the goal but the implementation was clunky 
and artificial.
- A paper document, where I am largely unrestricted by the tools. I can use a 
pencil, pen, paint, fuzzy felt, typewriter, crayons, &c. On the whole, one 
tool doesn't preclude the use of others. No one says, this paper can only be 
used for drafting, so you can only use these special pens that only draw lines 
and arcs - no crayons or freehand curves allowed!

>       * Technology / Implementation: Having a common base for handling
>         documents helps to save effort - LibO is already quite good when
>         it comes to re-using components. Funnily, this had been a matter
>         of limiting effort for the few guys working for StarDivision a
>         few years ago. The downside: less specialized handling for the
>         user's tasks ... which makes things less efficient. One of the
>         things that might need improvement are for example sharing some
>         "spreadsheet/table" code between Writer/Calc/Impress.

I have to make the code reuse versus specialisation call several time a week 
as a usability consultant working on improving the usability of enterprise 
software products (no names). It's a valid concern but I'd say that generally 
interaction consistency, reduction of potential points of divergence of 
behaviour and implementation efficiency are compelling reasons to take this 
approach. Concerns about specialisation can be handled by extending the base 
tool classes to introduce any required contextual subtleties. Still one tool 
but added capability for more nuanced application, according to context.

>       * Environment: The industry relies on certain decisions made in
>         the past. So changes in how documents are presented / handled
>         will also have impact on the document format ... this is (we
>         know that from political stuff) quite hard to handle :-)

I agree

>       * Usability: People still stick to what they learn when they are
>         small ... these real physical objects and their behavior are the
>         basis for (later) exploring computers and their enhanced
>         capabilities. And, although the ability of computers gained a
>         lot during the past years, the people still do have the same
>         mental capabilities (physiological stuff) - any change has to
>         consider that (will it be focusing on the tool, or the work).

As you might guess, I'd claim that having a richer palette of tools and 
capability without hard artificial boundaries improves ease of use, providing 
the tools address genuine use cases accurately and are well designed to fulfil 
those use cases. Clearly there are affinities of tool sets to specific user 
tasks, which roughly map to the traditional office product split but this 
categorisation is a generic oversimplification of users' real tasks. If it 
were not, then the wonderful worlds of OLE/COM/DCOM wouldn't have emerged. In 
my view, there is much greater mileage in a generic document model, with full 
access to it by all tools (ie things that manipulate the content and 
attributes of the model) and presentation of the model achieved through an 
extensible set of views. In practical user terms, the palette of views start 
with the usual suspects: a document to be printed, a document to be presented 
via projector, a screen based form document, a conference flyer, table based 
calculations, a novel, a colouring book for kids &c. For each of these, users 
are likely to use a particular set of tools to achieve most of the work but I 
don't see why they should be restricted to that set.The views could promote 
and bundle tools according to the implied user tasks. Being just views, rather 
than applications, it would be a simpler job to devise a new view, to meet a 
new use case and package it with the primary tools front and centre 
(discovered through user validation and observation). All the other tools 
would still be available to a user who strays from the specific use case (not 
a bad thing). In most cases the user may see something very much like their 
current application centric office suite. There, the boundaries are hard and 
crossing them a considerable effort. Here, the boundaries are flexible, to 
allow the product to mould more readily to new circumstances by bundling views 
and tools to address specific use cases. 

Some other random thoughts I'd like to consider (I haven't really thought them 
through much ;o) One is the tagging of view and tools. e.g. a default set of 
tags that help define the relationships between the tools and views but maybe 
also user definable tags. I'd hope this would allow view based tool 
availability, as well as context driven tool and view availability and any 
other orthogonal classification specified or derived... 

And another... MS's outline view. It's just too useful to not replicate and 
improve on. Especially for planning documents of any length. It certainly 
helps introduce structure and makes the proper use of styles more logical and 
intuitive. On the topic of Styles - Really important to do but difficult to do 
well. No application I know of has really cracked it to the extent that new 
users use it because it's intuitive and easy. If we could do that then it 
could be a real 'selling' point (GPL definition of selling ;o)
> There have been numerous approaches to apply such concepts, e.g. OS/2
> handling "objects" instead of applications, or "StarWriter 3.0" being
> claimed the "object-oriented word processor" (some of the functionality
> has been dropped already, since normal people don't understand some of
> these concepts derived from OOP).

I used to work with the IBM Boca team who produced OS/2. Both interesting and 
frustrating ;o)
> Consequently, I do support your general approach - the questions (and
> these are very fundamental UX questions) is: "Where to draw the line?
> What is the ideal trade-off?"
I agree, those are critical questions. I guess setting a baseline design 
philosophy is a start, followed by user research and a considerable amount of 
dialogue to identify the optimum approach as circumstances arise (optimum 
isn't meant to be dogmatic idealism by the way, I'd say it's much more 
pragmatic)
> Example:
>       * Writer is used to write documents with a continuous information
>         flow. You can write in "Weblayout" and the content gets printed
>         on pages, or published on websites
>       * To make it more versatile, you can introduce the idea of
>         connected frames for that - this comes close capabilities of DTP
>         applications. KOffice (for example) used that concept and
>         provided pre-positioned frames for the normal pages.
>       * More freedom can be given if people can position the frames how
>         they like. Then they can add different content like tables,
>         pictures, ... And it is rather easy to further derive different
>         renderings.
>
> But, the more abstract the concept, the more work to be done to start
> working. And then you need a way how people can start working
> efficiently ... and today, the feature set for particular tasks is
> wrapped in applications.
>
> Today, you find any of the concepts in (e.g.):
>       * Applications (group functionality)
>       * Views (e.g. Impress lets you see the same content in different
>         renderings, structures)
>       * Templates (pre-defined document elements)
>       * Single features (like frames, tables, ...)
>       * OLE objects (embed content from other applications)
>
> Interesting approaches to "break" some of the older concepts are (from
> my point-of-view):
>       * The MS Office 2010 "Backstage View": It finally resolve the
>         problem of "working on the real content", "handle meta data or
>         the document". Great approach! Something we will be faced to in
>         the near future, I think.
>       * Apple Numbers: Gets rid of pre-defined tables - instead, a
>         document gets created by adding individual tables on an "empty"
>         sheet. Also a very thoughtful way of adapting the software to
>         the today's needs.
This is a spreadsheet version of what I'm getting at. Imagine the same 
slickness and capability but with (optional / non-exclusive) task based 
boundaries to simplify understanding, rather than the user limiting 
application boundaries!
>       * Lotus Symphony: Tends to go back to "Symphony is the
>         application, and handles various document types".
Lotus has a mixed record on usability {Notes :o(  Smart Suite :o[  Lotus Live 
:o) Sametime :o)    }
> > Of course, the toolset and the rendering mechanisms could be extended in
> > a modular way, making the development time-line much more appropriate to
> > an open source community, with competition for tool developers to build
> > a better tool. If the core design team act in an editorial and standards
> > capacity, then the result can hang together seamlessly. (Apple seems to
> > have cracked this a bit ;o)
>
> Technology wise, the KOffice team did a great job ...
> http://www.koffice.org/
>
> And as I said, we not that bad ... but we can get better :-)
>
> > Enough rambling from me. I'd be really interested to see if there's
> > anyone else who gets what I'm on about and whether there's enough
> > interest to start investigating in more detail. If on the other hand you
> > think I've got it all wrong, I'm happy to defend my views or admit
> > defeat, depending on the feedback.
>
> Oh, no rambling ... you just point on some very important questions that
> have to be resolved for LibreOffice and how we enable both more
> efficient and effective working on contents for our users. Nevertheless,
> from my experience, there will never be a final "black/white" decision,
> but we can head towards a certain approach.
>
> Thus, I really appreciate to get this discussion started ... but the
> rest of the day will be dedicated to some more Design team kick-off.
>
> > If you read this far, well done :o)
>
> If you read my reply, good job as well ;-)
>
> Cheers,
> Christoph
Cheers,
Greg

-- 
Unsubscribe instructions: E-mail to design+help@libreoffice.org
List archive: http://listarchives.libreoffice.org/www/design/
*** All posts to this list are publicly archived for eternity ***