Re: [libreoffice-design] Design principles

2012/5/6 Stefan Knorr (Astron) <heinzlesspam@googlemail.com>

> Hi Mirek,
>
> > Even an advanced office suite needs to be focused.
> > As I specified, I see Writer as a tool to create great-looking documents.
> > That doesn't mean it can't export to HTML -- of course it can. An HTML
> > document is just as valuable as an ODT document. What it does mean,
> though,
> > is that Writer's workflow needs to be concentrated at creating a
> > great-looking document. All the tools within Writer should help the user
> do
> > that.
> > If the user wants to create a website with Writer (which I wouldn't
> > recommend, as there are better tools for that), he can download an
> > extension to help him accomplish that.
> >
> > For office productivity software, one of the important things are
> > > comparison tables. In these tables, things like "exports to HTML,"
> > > "support format XYZ," "can create organigrammes" all get you "points."
> > > So, that's where this project comes from: trying to match MSO in a
> > > comparison table + a little authentic innovation.
> >
> > I guess we have very different ideas about what LibreOffice should be.
> > I'd like LibreOffice to stand its own, have value not as a Microsoft
> > alternative but as a powerful suite of applications that each has its
> > specific goal and meaning.
>
> Our ideas where it should be are not so different, I think. :)

ok, good :)


> However, the most important (paying) customers for LibreOffice are
> huge bureaucracies that will indeed create a table of necessary
> features and use that to compare the available solutions. So, that's
> what the core developers get paid for, too. Specifically:
> * fixing crashes/freezes
> * improving performance
> * matching MSO features (to ease migration)
> * opening foreign file formats (to ease migration)

Out of all of these, only matching MS Office features has some influence on
the UI design.
My stance is this: LibreOffice should be able to import Office files as
precisely as possible.
We should craft GUIs for Office features that match our principles (which
is the vast majority, IMHO) and integrate them well with our UI and leave
GUIs for those that don't up for extensions.

> Also, a likely factor in LibO having so many half-baked features is
> that it's so much more interesting to do something new than to improve
> someone else's stuff. In that way, LibO's organicity also is a huge
> burden.


> > File format support is important, I agree, but it has no influence on
> how a
> > piece of software is designed.
>
> Well, these were examples.
>
> > The scanner module could actually be very useful if done correctly,
> perhaps
> > if included as a tab under the Insert image dialog.
>
> I believe that scanning isn't part of LibO's core competences (we
> don't even have a pixel image editor)


I've always wanted Draw to develop into a hybrid bitmap+vector editor,
something like what Macromedia Fireworks used to be.

and that all current OS's
> include better tools already.


Yeah, but by using LibreOffice's tool, you can scan directly into the
document instead of scanning with a different tool, saving as a picture,
then having to import it into LibreOffice.
That said, I really have no idea how much this tool is used.

In the case where they (Windows XP and
> Mac OS 10.4/5 (?)), such a tool always comes with the scanner itself.
> Thus, integrating with these tools should be the best idea there.


It'd be ideal, I agree, but I'm not sure if it'd be possible (there's a
cornucopia of scanner programs out there). We could integrate with the
commonly-used open-source Linux scanning programs, though...

-- 
Unsubscribe instructions: E-mail to design+help@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted