Re: [tdf-discuss] UI proposal

 HI everyone,

2010/10/23 Povilas Kanapickas <povilaskan@gmail.com>

> On Sat, Oct 23, 2010 at 1:42 PM, Ian <ian.lynch@theingots.org> wrote:
>
> > On Sat, 2010-10-23 at 01:58 +0300, Povilas Kanapickas wrote:
> > > First of
> > > all, Office suite should include a tool to make at least moderate
> quality
> > > schemes and similar things. That tool should be also integrated within
> > the
> > > suite, so it'd be possible to edit embedded graphics directly.
> >
> > Yes but ideally also able to stand alone from the suite for use in other
> > circumstances. Integration through internal messaging between
> > applications is perfectly possible. In Inkscape, raster graphics can be
> > embedded and various effects applied through the extensions. I can't see
> > it being impossible to add editing as another extension but maybe a
> > better approach is to communicate with other editors already in
> > existence. Embedding pngs seems to produce svg flies about 30% bigger
> > than the originals from a quick and unscientific check. Double click a
> > graphic and automatically open it in a raster editor would be another
> > possibility with "save" returning the edited image back to Inkscape.
> > That would require some open standard protocols to be defined for
> > transfer of data between apps (if it doesn't already exist). Drag and
> > drop between different apps supporting the standard would be another
> > possibility. It's really only a way of short-cutting cut and paste.
>
>
> By saying 'integrated' I didn't mean that we should have one application to
> do all the things. I meant that the interaction between these two
> applications should be polished. The word processor and drawing application
> must be able to work independently (and be installed as such). But when the
> user wants both of there two applications for one document, he shouldn't be
> forced to do awkward things such as to open the drawing
> application manually and so on.


This reminds me of a good presentation on how applications' features tend to
overlap and how, ideally, they should integrate with each other instead:
http://www.youtube.com/watch?v=3UwZkKsWgc0
Ideally, LibO should have a practically unlimited feature span. A user
should be able to get to every command that's POSSIBLE, not just built in.
The goal would be to have a search box that would do everything. A user
would type "Make this text bold" and a result would come up that would make
his text bold. Ideally, there should be even results for vague entries, like
"Make this document pretty" -- that should at least return a result with
document templates.
How would that be done?
Well, there is a bunch of OOo tutorials, guides, and walkthroughs online
already, and this number will only get bigger. If the creator of these could
only in some simple way mark the actions described in the tutorial for LibO
to read, LibO could reproduce all the steps taken in the tutorial.
This kind of tutorial could also use commands from third-party extensions
and applications.
How would this tutorial get made? I'm thinking a simple extension that gives
you a "Record my steps" button.

> > The more
> > > powerful the integrated graphic editor is, the less there will be users
> > who
> > > need to do the 'long trip' just to edit a graphic object (by saying
> long
> > > trip I mean deleting the object, finding the image in the file manager,
> > > opening it, editing, embedding into right location and adjusting image
> > > parameters). This is the reason, why the solution 'Let's just have
> Draw,
> > and
> > > leave Inkscape for the advanced users' isn't viable. In addition to
> that,
> > > why to decentralize the (scarce??) resources available?
> > >
> > > Of course, I wouldn't be saying all that if there were usability
> problems
> > > with Inkscape. But IMHO it has quite low learning curve while providing
> a
> > > lot of features.
> >
> > Agreed. What we need is innovation to get away from the megalithic
> > approach and build cross platform standards that support data messaging
> > between applications. Then smaller applications that are easier to
> > develop and manage are possible, working together or apart as required.
> > With phone technologies moving into the computer space this becomes more
> > important to help with power consumption, cost etc.
> Exactly. Actually that's why I'm advocating for using external graphics
> tool
> such as Inkscape. Inkscape is too big that it could be merged with LibO,
> even if we wanted. The only way for LibO to work with Inkscape is to
> provide
> an API and to make Inkscape to use it. Then, since the API is the only link
> binding LibO with Inkscape, it would be very easy to add support for other
> tools. Ideally, the user could choose whatever supported graphic editor he
> wanted and to have good user's experience at the same time.
>
> -
> Povilas
>
> --
> E-mail to discuss+help@documentfoundation.org<discuss%2Bhelp@documentfoundation.org>for 
> instructions on how to unsubscribe
> List archives are available at
> http://www.documentfoundation.org/lists/discuss/
> All messages you send to this list will be publicly archived and cannot be
> deleted

-- 
E-mail to discuss+help@documentfoundation.org for instructions on how to unsubscribe
List archives are available at http://www.documentfoundation.org/lists/discuss/
All messages you send to this list will be publicly archived and cannot be deleted