Re: toolbar field 'Search Commands'

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: toolbar field 'Search Commands'

Vince42-3
Hi,

Graham Perrin schrieb:
> Joshua Martin wrote:
>> http://sites.google.com/site/fluxuserinterface/Home/writer_horizontal_accordion4.png

> The presence of 'Search Commands' in the toolbar reminds me that on Mac OS
> X:
> * 'Search Commands' field should not present in the toolbar
> * commands in a UI such as FLUX should remain compatible with 'Spotlight for
> Help' (highlighted at
> <http://www.diigo.com/annotated/ade05da6fadd607ddfbd30df8d2d76ae>); screen
> shot at <http://homepage.mac.com/madfax7/.Pictures/HelpMenuSearch.jpg>
> (referred from Miroslav Mazel's
> <http://ux.openoffice.org/servlets/ReadMsg?list=discuss&msgNo=1770>)
> demonstrates the effect.

While generally being d'accord with sticking to these best practices:
How would the command search work on OSes which don't have a system wide
search facility?

--
Cheers,                        \\|//
Vince                          (o o)
----------------------------ooO-(_)-Ooo-------------------------
 '''   (o)_(o)                                        [ ][0][ ]
 ô¿ô   (=°o°=)   World Domination by Copy and Paste   [ ][ ][0]
  -    (")_(")                                        [0][0][0]

 ()  ascii ribbon campaign - against html e-mail
 /\  www.asciiribbon.org   - against proprietary attachments
                                   Ooo.
---------------------------.ooO----(  )-------------------------
                           (  )    (_/
                            \_)

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

OS-specific features: extensions, I guess

Graham Perrin
Administrator
Vincent - D. Ertner wrote
How would the […] work on OSes which don't have a system wide […] facility?
I guess, as OS-specific extensions to OOo.

Cheers
Graham
Reply | Threaded
Open this post in threaded view
|

Re: OS-specific features: extensions, I guess

DrewJensen
Graham Perrin wrote:

> Vincent - D. Ertner wrote:
>  
>> How would the […] work on OSes which don't have a system wide […]
>> facility?
>>
>>    
>
> I guess, as OS-specific extensions to OOo.
>
>  

Well, it sounds turned around backwards to me.

The OS with the special service would merit the extension.

Drew



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Extensions as extenders (not extensions as subtracters)

Graham Perrin
Administrator
Drew Jensen wrote
>> How would the […] work on OSes which don't have a system wide […]
>> facility?
>
> I guess, as OS-specific extensions to OOo.

Well, it sounds turned around backwards to me.

The OS with the special service would merit the extension.
The OS that provides the feature does not require OOo to duplicate the feature.

The OSes that lack the feature may benefit from an extended OOo that provides the feature.

A rationale:

* increase the weight, the core of OOo only where necessary (keep it lean)

* don't increase the weight of OOo for all platforms *and* require some users to add the weight of a slimming extension ;)

An extension should extend (add features), not subtract.

Happy new year!
Graham
Reply | Threaded
Open this post in threaded view
|

Re: Extensions as extenders (not extensions as subtracters)

DrewJensen
Graham Perrin wrote:

> Drew Jensen wrote:
>  
>>>> How would the […] work on OSes which don't have a system wide […]
>>>> facility?
>>>>        
>>> I guess, as OS-specific extensions to OOo.
>>>      
>> Well, it sounds turned around backwards to me.
>>
>> The OS with the special service would merit the extension.
>>
>>    
>
> The OS that provides the feature does not require OOo to duplicate the
> feature.
>
> The OSes that lack the feature may benefit from an extended OOo that
> provides the feature.
>
> A rationale:
>
> * increase the weight, the core of OOo only where necessary (keep it lean)
>
> * don't increase the weight of OOo for all platforms *and* require some
> users to add the weight of a slimming extension ;)
>
> An extension should extend (add features), not subtract.
>  


My understanding of what is being discussed here:
Adding a new core feature to OO.o that will be available to all users on
all platforms.

The UI for this feature should therefore, IMO, present to the users on
all platforms in a similar fashion.

As it happens there is one platform that offers an alternative, native
capability, for presenting the UI for the feature's functionality.
In such a case I would suggest to handle this not by special casing the
core package code, rather creating an appropriate API during the
development stage such that an extension - specific to this platform -
can be built. The extension does not remove any functionality from the
core package, it simply hooks into the core and offers to utilize the
platform native UI instead of the OO.o native UI.

And a most Happy New Year to you also,

Drew


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

'Search Commands' in an OOo toolbar: discussing an extension (non-core) approach

Graham Perrin
Administrator
(discussion moved to discuss@ux.openoffice.org where AFAIR most other discussion on this subject
Drew Jensen wrote
Graham Perrin wrote:

> The OS that provides the feature does not require OOo to duplicate
> the feature.
>
> The OSes that lack the feature may benefit from an extended OOo
> that provides the feature.
>
> A rationale:
>
> * increase the weight, the core of OOo only where necessary (keep
> it lean)
>
> * don't increase the weight of OOo for all platforms *and* require
> some users to add the weight of a slimming extension ;)
>
> An extension should extend (add features), not subtract.

My understanding of what is being discussed here:
Adding a new core feature to OO.o that will be available to all users on all platforms.
-1 to core (but I lack a technical understanding of what Drew describes below)

+1 to an extension approach that caters for Windows and Linux.

The UI for this feature should therefore, IMO, present to the users on all platforms in a similar fashion.
-1 (but I lack a technical understanding of what Drew describes below)

IMO this feature _must never_ present on Mac OS X, because here the feature is (with respect) duplication, entirely superfluous.

(I do recognise the value of the feature to users of other OSes :)

OOo should be primarily a good OS citizen, following guidelines.

OOo should not primarily gain a peculiar behaviour, which secondarily requires an extension to suppress/remove the behaviour.

… I would suggest to handle this not by special casing the core package code, rather creating an appropriate API during the development stage such that an extension - specific to this platform - can be built. The extension does not remove any functionality from the core package, it simply hooks into the core and offers to utilize the platform native UI instead of the OO.o native UI.

And a most Happy New Year to you also,

Drew
My main concern is that OOo is slow to load and sometimes slow to respond.

If Drew's suggestion does not increase the load/response times of the application, and if the un-Mac-like feature never appears in Mac OS X, then all is good :)

Maybe I'm misunderstanding extensions. Confession: I don't do code!

Best,
Graham
Reply | Threaded
Open this post in threaded view
|

Re: 'Search Commands' in an OOo toolbar: discussing an extension (non-core) approach

DrewJensen
Graham Perrin wrote:

> (discussion moved to [hidden email] where AFAIR most other
> discussion on this subject
>
> Drew Jensen wrote:
>  
>> Graham Perrin wrote:
>>
>>    
>>> The OS that provides the feature does not require OOo to duplicate
>>> the feature.
>>>
>>> The OSes that lack the feature may benefit from an extended OOo
>>> that provides the feature.
>>>
>>> A rationale:
>>>
>>> * increase the weight, the core of OOo only where necessary (keep
>>> it lean)
>>>
>>> * don't increase the weight of OOo for all platforms *and* require
>>> some users to add the weight of a slimming extension ;)
>>>
>>> An extension should extend (add features), not subtract.
>>>      
>> My understanding of what is being discussed here:
>> Adding a new core feature to OO.o that will be available to all users on
>> all platforms.
>>
>>    
>
> -1 to core (but I lack a technical understanding of what Drew describes
> below)
>
> +1 to an extension approach that caters for Windows and Linux.
>
>
>
>  
>> The UI for this feature should therefore, IMO, present to the users on all
>> platforms in a similar fashion.
>>
>>    
>
> -1 (but I lack a technical understanding of what Drew describes below)
>
> IMO this feature _must never_ present on Mac OS X, because here the feature
> is (with respect) duplication, entirely superfluous.
>
> (I do recognise the value of the feature to users of other OSes :)
>
> OOo should be primarily a good OS citizen, following guidelines.
>
> OOo should not primarily gain a peculiar behaviour, which secondarily
> requires an extension to suppress/remove the behaviour.
>
>
>
>  
>> … I would suggest to handle this not by special casing the core package
>> code, rather creating an appropriate API during the development stage such
>> that an extension - specific to this platform - can be built. The
>> extension does not remove any functionality from the core package, it
>> simply hooks into the core and offers to utilize the platform native UI
>> instead of the OO.o native UI.
>>
>> And a most Happy New Year to you also,
>>
>> Drew
>>
>>    
>
> My main concern is that OOo is slow to load and sometimes slow to respond.
>
> If Drew's suggestion does not increase the load/response times of the
> application, and if the un-Mac-like feature never appears in Mac OS X, then
> all is good :)
>
> Maybe I'm misunderstanding extensions. Confession: I don't do code!
>
> Best,
> Graham
>  


Actually how to implement anything is OT for this list. I was just
playing off your remarks about extensions and should not have gone there.

The question regarding UI for a cross-platform application - I suppose
that is germane. (on either list)

For example:

I thought the FLUX designer was going for no top level menu - then there
is a post about this being non-negotiable on the Mac - so where is that now?
No top level menu for MS Win, Linux, Solaris - Yes top level menu for Mac?

What are we really saying here - if a Windows, Linux or Solaris user
upgrades at some point and the top level menu system just disappears
they will be able to handle the change - but if that happens for a Mac
user they just won't be able to cope? In the end isn't the question
really  - is not having a top level menu system a better design? If the
answer is yes, then is it not yes for all platforms?

Anyway - I know that I'm venturing out onto the thin ice here when it
comes to the Mac and really don't want to end up in the cold waters -
still, that is how I see it.

Respectfully,

Drew


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

not confusing Renaissance with the presence of features that are out-of-scope

Graham Perrin
Administrator
In reply to this post by Graham Perrin
With apologies for cross-posting

On 31st December, I moved the relevant thread to [hidden email]
  but (at this time) I can not offer an openoffice.org reference; we  
have some problems with the list archive (messages posted after 29th  
December seem to be missing).

@ [hidden email]

<http://wiki.services.openoffice.org/wiki/Renaissance:The_Scope>  
reminds us of the one and only thing that is _out of scope_:

>> Anything that users can currently not accomplish with OpenOffice.org

-- and so (please) within the Renaissance mock-ups, features that are  
not implemented feature (such as, 'Search Commands') should not appear.

----

On 1 Jan 2009, at 22:46, Clément Pillias wrote:

> I believe that one of the goals of Renaissance should be to make OOo  
> integrate well/better with the OS guidelines and features.

+1

but <http://wiki.services.openoffice.org/wiki/Renaissance:The_Goal>  
does not express this. If a member of Renaissance team could review  
and update, it will be much appreciated. If it *is* amongst the goals,  
please make the statement at the wiki. If it is *not* amongst the  
goals, or if it is in any way out of scope, again please update the  
wiki.

Thanks and regards
Graham
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 'Search Commands' in an OOo toolbar: discussing an extension (non-core) approach

Clément Pillias
In reply to this post by DrewJensen
Hi Graham, Drew, and everybody involved in the 'search command'  
discussion.

>>> Graham Perrin wrote:
>>>> The OS that provides the feature does not require OOo to  
>>>> duplicate the feature.
>>>>
>>>> The OSes that lack the feature may benefit from an extended OOo  
>>>> that provides the feature.

I would say that an OS that lack the feature would benefit from a  
piece of software providing the feature at the OS level, and not only  
at OOo's application level.

I have searched for such a project, but I don't have find anything yet.

If we plan to work on such a feature for OOo and face the  
difficulties of development for Windows and X11-based OSes, I think  
that we should start a project that does not concern OOo only. Let me  
highlight the benefits from the marketing, user experience and  
development points of view:

 From the marketing point of view, we create a useful software aiming  
at a larger user base than OOo. Because this is a small, simple and  
very useful program, we can suppose that it will spread faster than  
the big OOo, because of a smaller entrance barrier. So we first use  
OOo's marketing weight to diffuse the new software, but at the end it  
will certainly be the reverse: people using and enjoying the small  
software may be more willing to install and try the big one.

This new software also transmits OOo's values in term of productivity  
and user experience. It shows that, as a software provider, we are  
not only concerned by our own main product, but take care of our  
users needs at a higher level.

 From the user experience point of view, it is of course better to  
have the feature work in all/most applications rather than in only  
one. It is also more coherent. And an important point is that we let  
the user decide how he wants to interact with his whole computer,  
rather than forcing him to use (or ignore) the interaction model that  
we selected.

 From the developer's point of view, developing a system-wide  
application rather than some application feature has certainly a  
cost. But since the application aim at a bigger target, we can also  
suppose that it will attract more developers, and get support from  
the main Linux distributions (for the linux port). This also  
reinforce OOo's position in the world of free software.

And moreover we benefit from separation: the software is easier to  
maintain and we can have new releases more often.


> Graham Perrin wrote:
>> Drew Jensen wrote:
>>> The UI for this feature should therefore, IMO, present to the  
>>> users on all platforms in a similar fashion.
>>
>> -1 (but I lack a technical understanding of what Drew describes  
>> below)

I agree here with Graham.

>> IMO this feature _must never_ present on Mac OS X, because here  
>> the feature is (with respect) duplication, entirely superfluous.
>> (I do recognise the value of the feature to users of other OSes :)
>>
>> OOo should be primarily a good OS citizen, following guidelines.
>>
>> OOo should not primarily gain a peculiar behaviour, which  
>> secondarily requires an extension to suppress/remove the behaviour.

These are more reasons to provide the 'behavior' as a system-wide  
service.

Regards,

Clément.

PS: in all the discussion, "help menu search" has been referred as a  
"mac OS X feature". But it is in fact only a "mac OS X Leopard (10.5)  
feature". So many mac users that are still using an older version of  
the OS (like me) would also be interested by the feature.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 'Search Commands' in an OOo toolbar: discussing an extension (non-core) approach

Graham Perrin
Administrator
On 3 Jan 2009, at 14:43, Clément Pillias wrote:

> PS: in all the discussion, "help menu search" has been referred as a  
> "mac OS X feature". But it is in fact only a "mac OS X Leopard  
> (10.5) feature".

The distinction was introduced on 28th November,
<http://ux.openoffice.org/servlets/ReadMsg?listName=discuss&msgNo=2518>

>> On Mac OS X 10.5.x, the one and only place for an approach such as  
>> this is _within_ (never alongside) the Help menu

Admittedly I might have made that distinction more obvious.

Oversights are allowed :) (and I have masses of catching up to do in  
neighbouring ui@ux …)

Also in November I made corresponding additions to <http://wiki.services.openoffice.org/wiki/User_Experience/Resources#Other_Sources 
 >.

Focusing on <http://wiki.services.openoffice.org/wiki/User_Experience/Resources#Open_Source_Software 
 > with regard to quality, I almost certainly have more to come in the  
next few days. When it comes it will probably in the form of a *very  
brief* e-mail cross-posted to discuss@ux and ui@ux simply referring to  
a forum elsewhere.

> mac users that are still using an older version of the OS (like me)  
> would also be interested by the feature.

An excellent point, of which I had lost sight in the past month!

Yes, oversights are not only allowed, I sometimes positively  
*encourage* a distanced view that takes little or notice of detailed/
heated debate. The step back and time off allows us to think beyond  
OpenOffice.org Island and I very much like the possibilities within in  
Clément's e-mail.

I still have not read 'User Experience/Command search' in its entirety  
but at <http://wiki.services.openoffice.org/wiki/User_Experience/Command_search#To_do 
 > I value and look forward patiently to the point at which

>>> developers can weigh in on implementation options (arguments, use  
>>> of Ubiquity code)

<http://www.openoffice.org/dev_docs/source/sys_reqs_30.html> reminds  
us that for users of OOo 3 on Mac OS X, version 10.4 is the baseline.

---

As a potential seed (for possible later discussion in another forum,  
*not* in ux):

if there are any notions of Java in relation to the 'Search Commands'  
feature,
then consider:

1) on the most recent Mac OS X 10.4.x, AFAIK:

* J2SE 5.0 is 1.5.0_16
* Java 1.4 is 1.4.2_18.

2) on a most recent Mac OS 10.5.6:

java version "1.5.0_16"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-
b06-277)
Java HotSpot(TM) Client VM (build 1.5.0_16-130, mixed mode, sharing)

Key point: the _absence_ of J2SE 6.x (1.6.x).

(There is the SoyLatte port <http://landonf.bikemonkey.org/static/soylatte/ 
 > but we should not assume that users can take that route.)

Regards
Graham

Afterthought: I should not add a reference from ux wiki to <http://www.openoffice.org/dev_docs/source/sys_reqs_30.html 
 >; the requirements there are wrong/incomplete.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 'Search Commands' in an OOo toolbar: discussing an extension (non-core) approach

Philip Ganchev
In reply to this post by Clément Pillias
On Sat, Jan 3, 2009 at 9:43 AM, Clément Pillias <[hidden email]> wrote:
> I would say that an OS that lack the feature would benefit from a piece of
> software providing the feature at the OS level, and not only at OOo's
> application level.

That would be best, if we have the development resources. In that
case, the command names will not be customized -- they will be just
the menu paths. I think this is OK, and I had given up on custom
command names anyway.

What input do we need from other projects, such as Xorg, Gnome, KDE?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 'Search Commands' in an OOo toolbar: discussing an extension (non-core) approach

Graham Perrin
Administrator
In reply to this post by DrewJensen
Drew Jensen wrote
… venturing out onto the thin ice here when it comes to the Mac and really don't want to end up in the cold waters - still, that is how I see it.

Respectfully,

Drew
Drew and all: the ice is not thin; and if anyone should slip, there will be rescue :)