[libreoffice-design] Default Templates

2011-02-14 Thread noh.way.jose
I hate Times New Roman (or pretty much any other serif font) as the default 
font. I would mind it less if it were easy to change the style in the default 
template easily but it's generally an unintuitive task, even when reading the 
sparse documentation. The Organise Templates dialogue is a mysterious 
concoction of esoteric and seeming irrelevant cul de sacs.

Before all the HCI grads and typographers out there shout that serif fonts are 
more readable,  a) I disagree for on-screen reading and generally find sans 
serif easier on my eye in printed form unless the font size is small  b) I 
don't believe there is a definitive choice between the two and c) even if I 
agreed, it should be much easier for a user to select to change attributes of 
the default  template. and (tongue in cheek) z) Times New Roman seems like a 
lazy choice based on what Microsoft Office does in the US.

I propose that we change the default text style in the default template to a 
clear sans-serif choice and while there, set the paragraph spacing to 0.5em, 
before and after, so that users aren't encouraged to separate paragraphs with 
double CRLF. As you'll see from the proportional unit I've suggested, we'll 
need em units in the product (the width of a letter m in the chosen font - 
those of you familiar with CSS will know this one). I also propose that we 
sort out the horrible mess that is the Organise Templates dialogue. 

Just to get started here's a straw man for a user story (Agile):

As a user of LibreOffice, who has just downloaded and installed the product, I 
wish to ensure every document I create from here on is styled the way I 
prefer, so that I don't have to manually adjust the styles each time.

This is covered by the default template, except where a user doesn't like some 
aspect of the template, because updating it is a pain in the neck.

-- 
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] Different design disciplines

2011-02-14 Thread noh.way.jose
A question:

Is this forum the right place for product architecture? I thought that's what 
I was getting involved in but it seems focused a great deal more on graphic 
design.

I'm not complaining, it's just that I know there are many design disciplines 
and I had the former in mind, rather than the latter. Maybe it's just a point 
in time trend?

Regards,

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



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

2011-02-01 Thread noh.way.jose
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 traditional office product split but this 
categorisation is a generic oversimplification

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

2011-01-27 Thread 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


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