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 + 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 traditi
Re: [libreoffice-design] Breaking out of the box (applications versus objects)
Hi Greg, all, a lot has been said on this topic and as I don't like to write lengthy mails, I just want to shortly point one thought that I think is missing in the discussion so far: People care neither about applications nor about objects. They care about tasks (or workflows, as you like). And this is a topic we - as an application provider - probably cannot solve. But we need to be aware of it. I think on the long run, all we can do is to provide a solid technology base, that can be used by operating systems to help users to manage their tasks. Writing a personal letter to Greg is something totally different than writing a book about the future of user-interfaces. Atm I use writer for both of it. Very unsatisfying :) Best, Björn Am Freitag, 28. Januar 2011, 00:44:46 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. > > To set the scene, first a bit of summarised, probably partisan and probably > only partially accurate context. I point this out because I wouldn't want > the thread to spin off into pedantic historic details and corrections. > > Having been around the computer industry for many years now, I have kept > abreast of computing advancements by reading the industry news, developing > products and using them. A pattern of acquisitions, mergers,aggregations, > best practice, standards and plain copying has been going on so > relentlessly that I believe that the fruits of these enterprises no longer > adequately meet users needs as well as can be. > > The original modern interface (Xerox Star) didn't differentiate by > application but by objects familiar to users. The application rot started > with the commercial versions of this approach but really got application > centric with Windows '95. My rough recollection is that MS Office started > as a bunch of acquisitions that map pretty much to the applications we see > now, whether MS, OOO or LO. That is; a word processor, a presentation > manager, a spreadsheet and a database. Leaving the DB out of the argument > for the moment, as a non presentation centric technology, I'd like to > propose Libre Office consider a mid to long term strategy to ditch the > artificial boundaries between applications. Let us return to the idea of > supporting users' needs without filtering them through artificial > application capabilities! > > 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. > > 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) > > 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. > > If you read this far, well done :o) > > Cheers, > > Greg -- Voluntary Open Source Usability: http://www.OpenUsability.org Commercial Open Source Usability: http://www.OpenSource-Usability-Labs.com -- Unsubscribe instructions: E-mail to design+h...@libreoffice.org List archive: http://listarchives.libreoffice.org/www/design/ *** All posts to this list are publicly archived for eternity ***
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 + 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 fi
Re: [libreoffice-design] Breaking out of the box (applications versus objects)
Hi Greg! Before anything else, welcome from me, a recent members too! :) I like your approach and share your ideas. I actually think that at future, applications in general will be more integrate and unified like that. But personally I'd fell a bit uncomfortable if I'd have to do everything in a unique application. Sometimes is good have a different context to help when the workflow is changed. But as Bernhard well pointed, it's possible work in other applications inside one of them using OLE bjects. But I must to say the current implementation of this feature, his behavior, looks like a Frankenstein... :/ Maybe the great solution would be improve the OLE feature until the point its behavior gets closer at most to your proposal, Greg. ;) Best wishes, ~Paulo On 27-01-2011 22:44, noh.way.jose wrote: I'm new to this community, so please forgive me if the topic I'd like to discuss has already been aired. To set the scene, first a bit of summarised, probably partisan and probably only partially accurate context. I point this out because I wouldn't want the thread to spin off into pedantic historic details and corrections. Having been around the computer industry for many years now, I have kept abreast of computing advancements by reading the industry news, developing products and using them. A pattern of acquisitions, mergers,aggregations, best practice, standards and plain copying has been going on so relentlessly that I believe that the fruits of these enterprises no longer adequately meet users needs as well as can be. The original modern interface (Xerox Star) didn't differentiate by application but by objects familiar to users. The application rot started with the commercial versions of this approach but really got application centric with Windows '95. My rough recollection is that MS Office started as a bunch of acquisitions that map pretty much to the applications we see now, whether MS, OOO or LO. That is; a word processor, a presentation manager, a spreadsheet and a database. Leaving the DB out of the argument for the moment, as a non presentation centric technology, I'd like to propose Libre Office consider a mid to long term strategy to ditch the artificial boundaries between applications. Let us return to the idea of supporting users' needs without filtering them through artificial application capabilities! 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. 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) 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. If you read this far, well done :o) Cheers, Greg -- Paulo José O. Amaro Computer Science Student Federal University of São João del-Rei WebDesigner / Linked Empresa Júnior Blogger / casatwain.com -- Unsubscribe instructions: E-mail to design+h...@libreoffice.org List archive: http://listarchives.libreoffice.org/www/design/ *** All posts to this list are publicly archived for eternity ***
Re: [libreoffice-design] Breaking out of the box (applications versus objects)
On 01/28/2011 09:17 AM, Mike Houben wrote: yes I read it all and I'm fully with you. But what you are proposing here is not a Design choice it's a general choice and should be on the discuss Mailinglist from libreoffice. disc...@documentfoundation.org Of course it is a design choice. It should be motivated by UX design considerations, but would have consequences to deep down within the code. The discuss list ... where I had to unsubscribe because the sheer volume is unbearable, especially considering the signal/noise ratio. Open collaboration is such a nice concept, but I see again and again that wide open places where everyone talks lead to nothing but piles of words. What counts in the end is the work done, and the people who actually do it can't have the time to read a gazillion emails. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ -- Unsubscribe instructions: E-mail to design+h...@libreoffice.org List archive: http://listarchives.libreoffice.org/www/design/ *** All posts to this list are publicly archived for eternity ***
Re: [libreoffice-design] Breaking out of the box (applications versus objects)
On 01/28/2011 01:44 AM, noh.way.jose wrote: (...) Leaving the DB out of the argument for the moment, as a non presentation centric technology, I'd like to propose Libre Office consider a mid to long term strategy to ditch the artificial boundaries between applications. Let us return to the idea of supporting users' needs without filtering them through artificial application capabilities! Aside of reading and thinking about similar ideas once in a while in a more general context, I was reminded of this when writing the draft now found at http://wiki.documentfoundation.org/Mission Much of the current differentiation between some applications has likely more to do with marketing than with anything else, although managing complexity follows not that far behind (both on the architectural and user interface sides). I do think this is the right idea, but it will require many very deep changes. In the end starting from scratch could be easier. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ -- Unsubscribe instructions: E-mail to design+h...@libreoffice.org List archive: http://listarchives.libreoffice.org/www/design/ *** All posts to this list are publicly archived for eternity ***
Re: [libreoffice-design] Breaking out of the box (applications versus objects)
Hi Greg, *, yes I read it all and I'm fully with you. But what you are proposing here is not a Design choice it's a general choice and should be on the discuss Mailinglist from libreoffice. disc...@documentfoundation.org What I can say is that for the moment they have all the different applications work with shared scripts and all, to minimize the data they use. (I'm not going further because I'm not quit sure) I have forwarded this mail ;-) Houbsi On Fri, 28 Jan 2011 00:44:46 +, "noh.way.jose" wrote: > I'm new to this community, so please forgive me if the topic I'd like to > discuss has already been aired. > > To set the scene, first a bit of summarised, probably partisan and probably > > only partially accurate context. I point this out because I wouldn't want > the > thread to spin off into pedantic historic details and corrections. > > Having been around the computer industry for many years now, I have kept > abreast of computing advancements by reading the industry news, developing > products and using them. A pattern of acquisitions, mergers,aggregations, > best > practice, standards and plain copying has been going on so relentlessly > that I > believe that the fruits of these enterprises no longer adequately meet > users > needs as well as can be. > > The original modern interface (Xerox Star) didn't differentiate by > application > but by objects familiar to users. The application rot started with the > commercial versions of this approach but really got application centric > with > Windows '95. My rough recollection is that MS Office started as a bunch of > acquisitions that map pretty much to the applications we see now, whether > MS, > OOO or LO. That is; a word processor, a presentation manager, a spreadsheet > > and a database. Leaving the DB out of the argument for the moment, as a non > > presentation centric technology, I'd like to propose Libre Office consider > a > mid to long term strategy to ditch the artificial boundaries between > applications. Let us return to the idea of supporting users' needs without > filtering them through artificial application capabilities! > > 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. > > 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) > > 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. > > If you read this far, well done :o) > > Cheers, > > Greg -- Mike Houben UI - Coding - Animation http://www.crazyhstudio.net -- Unsubscribe instructions: E-mail to design+h...@libreoffice.org List archive: http://listarchives.libreoffice.org/www/design/ *** All posts to this list are publicly archived for eternity ***
[libreoffice-design] Breaking out of the box (applications versus objects)
I'm new to this community, so please forgive me if the topic I'd like to discuss has already been aired. To set the scene, first a bit of summarised, probably partisan and probably only partially accurate context. I point this out because I wouldn't want the thread to spin off into pedantic historic details and corrections. Having been around the computer industry for many years now, I have kept abreast of computing advancements by reading the industry news, developing products and using them. A pattern of acquisitions, mergers,aggregations, best practice, standards and plain copying has been going on so relentlessly that I believe that the fruits of these enterprises no longer adequately meet users needs as well as can be. The original modern interface (Xerox Star) didn't differentiate by application but by objects familiar to users. The application rot started with the commercial versions of this approach but really got application centric with Windows '95. My rough recollection is that MS Office started as a bunch of acquisitions that map pretty much to the applications we see now, whether MS, OOO or LO. That is; a word processor, a presentation manager, a spreadsheet and a database. Leaving the DB out of the argument for the moment, as a non presentation centric technology, I'd like to propose Libre Office consider a mid to long term strategy to ditch the artificial boundaries between applications. Let us return to the idea of supporting users' needs without filtering them through artificial application capabilities! 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. 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) 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. If you read this far, well done :o) Cheers, Greg -- Unsubscribe instructions: E-mail to design+h...@libreoffice.org List archive: http://listarchives.libreoffice.org/www/design/ *** All posts to this list are publicly archived for eternity ***
