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

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!

[...]

> 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.

      * 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.

      * 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 :-)

      * 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).

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).

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?"

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.
      * Lotus Symphony: Tends to go back to "Symphony is the
        application, and handles various document types".

> 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


-- 
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 ***