Re: [UX][DISCUSS] Default Document Border

[Kevin Grignon <ke...@gmail.com>]

KG02 - See comment inline.

On Fri, Sep 28, 2012 at 4:05 PM, Armin Le Grand <Ar...@me.com>wrote:

>         Hi,
>
>
> On 28.09.2012 03:22, Kevin Grignon wrote:
>
>> KG01 - See comments inline.
>>
>>
>> On Fri, Sep 28, 2012 at 7:54 AM, tj <tj...@apache.org> wrote:
>>
>>  On 9/27/2012 09:45, Kevin Grignon wrote:
>>>
>>>
> snip
>
>
>
>>> It's fairly obvious that some users like page framing (I do), and others
>>> don't. We could add a checkbox under Tools > Options > Writer >  View, in
>>> the "view" column: ☑ Page frame
>>>
>>> If you want to get elaborate, we could put some radio buttons underneath
>>> this option:
>>> • Chop marks
>>> • Corners
>>> • Borders ...
>>>
>>>
>> KG01 - yes, this is what I was thinking. How might we proceed? Sketch up
>> the solution? Seek a developer to implement?
>>
>
> I like the gereral idea, but I also agree that the default should be the
> old behaviour. This again means that nearly nobody will use the other
> possibilities (who changes defaults...?).
>
> Seeing that this task looks like a luxury problem to me. Should we really
> spend ressources in implementing four kinds of page document border
> visualisation (one existing, three fancy new ones)?
>
> With the points collected I would suggest just a slight change:
>
> - Use the existing possibility for changing the color of document borders
> to reduce the contrast, choose a lighter gray color for it and make it the
> new default.
>
> That's it. I would not do more currently.
>

KG02 - I agree. This is not a big deal for me. I stand by my original
design goals. I think we need to reduce the amount of noise, or non-content
UI within the editors. I appreciate that the page boarder helps orient
some, and helps others position objects - this is great. However, I feel
that it's presence is not needed all the time. From a cognitive
perspective, every pixel matters. Loosing the text cursor in the boader
dis-orients everyone, so some tradeoffs are needed hear to optimize the
design.

As I mentioned above, I can satisfy my design goal by reducing the darkness
of the default outline and improving the cursor/page boundary. In other
words, as Armin seconds, lets start by reducing the default boarder colour.

Finally, I agree with Armin. Other UI issues deserve more attention. Let's
keep the discussion focused on goals and ways to realize goals.



>
> There are more UI tasks where putting ressources will benefit more users
> IMHO...
>
>
>  where that last leads to a dialog such as can be found on "Border" tabs in
>>> various places, controlling line thickness, color, placement ...
>>>
>>>
>> KG01 -Interesting. I would say this is separate enhancement. My goal is to
>> reduce "noise" on the editing page, but be flexible to support contexts of
>> use where boarders are helpful guides.
>>
>> This is assuming that users who don't want frame marking would almost
>> never
>> use it. For users who want quick toggle (if there are any), we could add
>> an
>> entry to the "Writer > Formatting aids" list for what is shown when NPC is
>> selected.
>>
>> KG01 - Makes sense. Great idea.
>>
>>
>>  Note the importance of setting the defaults such that the current UI
>>> appearance is unchanged. Users who want changes should have to do a
>>> little
>>> work; those who don't, shouldn't.
>>>
>>>
>>>  KG01 - This is a difficult call. On one hand, the is significant
>> interest
>> in a refreshed UI. One that is lighter, more task focused and appears
>> contemporary. On the other hand, change can be difficult. I understand
>> that
>> Microsoft Office, which has significant instrumentation, data suggest that
>> only 5% of users customize their doc editor workspace. The goal should be
>> to provide the right default, a smart default that addresses the user's
>> goals and reinforces our design language. We need data to drive this, and
>> other similar decisions.
>>
>> KG01 - I will update the work item to include elements of this thread.
>>
>>
>>  snip
>
>
>>
> Sincerely,
>         Armin
> --
> ALG
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: ooo-users-unsubscribe@**incubator.apache.org<oo...@incubator.apache.org>
> For additional commands, e-mail: ooo-users-help@incubator.**apache.org<oo...@incubator.apache.org>
>
>