Removing Read Only mode

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

Removing Read Only mode

Camille Moulin-2
Dear UX team,

I have started listing the issues that, according to my own experience
and info from other large scale migrations, imped the most OOo's use in
an entreprise context.
There is a raw list :
http://wiki.services.openoffice.org/wiki/User:Camillem/MostProminentIssuesForEnterpriseUsage

but I also started trying to identify usage profiles and basic workflows

http://wiki.services.openoffice.org/wiki/User:Camillem/UserProfilesAndWorkflows

As you can see, it's still in very early stage, but it already
highlights a problem I'd like to tackle : the read only mode.

Basically,it's very disorientating for users, and I can't really see the
advantages it brings.
So, can anyone point out use cases where it's usefull/necessary?

Or can we consider starting studying the ways to remove it ? (i'm
getting very optimistic here)

Thanks,
Camille

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

Reply | Threaded
Open this post in threaded view
|

Re: Removing Read Only mode

Andreas Bartel-2
Hi Camille!

Awesome Job!


Yes, we are aware of this thing called modes :-) especially the one you mention below.

Our ideo for now was either to improve it dramatically or to remove As you suggested.

I guess Frank can provide more details about use cases. This is really something for Writer to start with.

Nice to have you back here!

Regards,

Andreas



--

http://www.oracle.com/
Andreas Bartel | User Experience Engineer
Phone: +49 040 23646 672

ORACLE Deutschland B.V.&  Co. KG | Nagelsweg 55 | 20097 Hamburg

ORACLE Deutschland B.V.&  Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Rijnzathe 6, 3454PV De Meern, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven


Oracle is committed to developing practices and products that help
protect the environment.

Am 08.10.2010 um 09:09 schrieb Camille Moulin <[hidden email]>:

> Dear UX team,
>
> I have started listing the issues that, according to my own experience
> and info from other large scale migrations, imped the most OOo's use in
> an entreprise context.
> There is a raw list :
> http://wiki.services.openoffice.org/wiki/User:Camillem/MostProminentIssuesForEnterpriseUsage
>
> but I also started trying to identify usage profiles and basic workflows
>
> http://wiki.services.openoffice.org/wiki/User:Camillem/UserProfilesAndWorkflows
>
> As you can see, it's still in very early stage, but it already
> highlights a problem I'd like to tackle : the read only mode.
>
> Basically,it's very disorientating for users, and I can't really see the
> advantages it brings.
> So, can anyone point out use cases where it's usefull/necessary?
>
> Or can we consider starting studying the ways to remove it ? (i'm
> getting very optimistic here)
>
> Thanks,
> Camille
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

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

Reply | Threaded
Open this post in threaded view
|

Re: Removing Read Only mode

Andreas Bartel-2
In reply to this post by Camille Moulin-2
.. very nice list by the way Camille! The Impress Renaissance iTeam has a meeting on Monday. We will go through the list and see what we are able to do about it.

Regards,
Andreas


Am 08.10.2010 um 09:09 schrieb Camille Moulin:

> Dear UX team,
>
> I have started listing the issues that, according to my own experience
> and info from other large scale migrations, imped the most OOo's use in
> an entreprise context.
> There is a raw list :
> http://wiki.services.openoffice.org/wiki/User:Camillem/MostProminentIssuesForEnterpriseUsage
>
> but I also started trying to identify usage profiles and basic workflows
>
> http://wiki.services.openoffice.org/wiki/User:Camillem/UserProfilesAndWorkflows
>
> As you can see, it's still in very early stage, but it already
> highlights a problem I'd like to tackle : the read only mode.
>
> Basically,it's very disorientating for users, and I can't really see the
> advantages it brings.
> So, can anyone point out use cases where it's usefull/necessary?
>
> Or can we consider starting studying the ways to remove it ? (i'm
> getting very optimistic here)
>
> Thanks,
> Camille
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>




Andreas Bartel | User Experience Engineer
Phone: +49 (0)40 236 46 - 672
Oracle OFFICE GBU

ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Rijnzathe 6, 3454PV De Meern, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven



Oracle is committed to developing practices and products that help protect the environment





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

Reply | Threaded
Open this post in threaded view
|

HA: [ux-discuss] Removing Read Only mode

Kirill S. Palagin
In reply to this post by Camille Moulin-2
There is even an issue for that
http://www.openoffice.org/issues/show_bug.cgi?id=73155

________________________________

От: Camille Moulin [mailto:[hidden email]]
Отправлено: Пт, 10/8/2010 11:09
Кому: [hidden email]
Тема: [ux-discuss] Removing Read Only mode



Dear UX team,

I have started listing the issues that, according to my own experience
and info from other large scale migrations, imped the most OOo's use in
an entreprise context.
There is a raw list :
http://wiki.services.openoffice.org/wiki/User:Camillem/MostProminentIssuesForEnterpriseUsage

but I also started trying to identify usage profiles and basic workflows

http://wiki.services.openoffice.org/wiki/User:Camillem/UserProfilesAndWorkflows

As you can see, it's still in very early stage, but it already
highlights a problem I'd like to tackle : the read only mode.

Basically,it's very disorientating for users, and I can't really see the
advantages it brings.
So, can anyone point out use cases where it's usefull/necessary?

Or can we consider starting studying the ways to remove it ? (i'm
getting very optimistic here)

Thanks,
Camille

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



Reply | Threaded
Open this post in threaded view
|

Re: HA: [ux-discuss] Removing Read Only mode

Camille Moulin-2
On 08/10/2010 13:11, Kirill S. Palagin wrote:
> There is even an issue for that
> http://www.openoffice.org/issues/show_bug.cgi?id=73155
Thanks for the link.
According to what I read there and on the dup ,
http://www.openoffice.org/issues/show_bug.cgi?id=75946
I just see more reasons to get rid of this.

So first step: what would we break from a ux pov if we removed it?

Camille


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

Reply | Threaded
Open this post in threaded view
|

Re: Removing Read Only mode

Andreas Säger
In reply to this post by Camille Moulin-2
Regarding issue 89232, I'd like to say that copy&paste preserves
filtered rows.

Issue 12666: You can even have many list ranges on the same sheet and
preserve all filter settings, sort orders and subtotal settings. Just
separate the list from other sheet content by naming it: Data>Define...

Issue 85305: Like any other spreadsheet reference, formulas, chart
ranges, validation formulas, conditional formattings, list sources and
named references, list ranges do dynamically adjust when you insert new
rows into the range or directly below the range. The latter (insert
below) works only if Tools>Options...Calc>General is set.

Using a most simple database solves most of the problems with dynamic
data ranges since a database has clearly defined row sets and Calc gets
a clearly defined row set from any type of database.

Greetings,
Andreas


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

Reply | Threaded
Open this post in threaded view
|

Re: Removing Read Only mode

Camille Moulin-2
Hi Andreas,

On 10/10/2010 21:54, Andreas Säger wrote:
> Regarding issue 89232, I'd like to say that copy&paste preserves
> filtered rows.

I know, it's a good thing, a nice progress, but in a way, that makes
Calc's behaviour even more inconsistent and unpredictable by the user.

> Issue 12666: You can even have many list ranges on the same sheet and
> preserve all filter settings, sort orders and subtotal settings. Just
> separate the list from other sheet content by naming it: Data>Define...

I'm already aware of that, and that's what we tell users to do. But
having to define a Database Range seems like unnecessary extra steps to
the user. And it's hard for him to understand why some thing done a
sheet (defining an autofilter) would affect another sheet (removing the
autofilter).

> Issue 85305: Like any other spreadsheet reference, formulas, chart
> ranges, validation formulas, conditional formattings, list sources and
> named references, list ranges do dynamically adjust when you insert new
> rows into the range or directly below the range. The latter (insert
> below) works only if Tools>Options...Calc>General is set.
Do you mean "Expands references when new columns/row are inserted" ?
It doesn't seem to work for me :-( (tested on OOO330m8)
Because actually I think it's normal that this options doesn't solve the
problem because in this case the user doesn't insert a new row, he just
adds data below the automatic range.

> Using a most simple database solves most of the problems with dynamic
> data ranges since a database has clearly defined row sets and Calc gets
> a clearly defined row set from any type of database.

Unfortunately, this won't fit in the real-life workflows I know about.


Best,
Camille

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

Reply | Threaded
Open this post in threaded view
|

Re: Removing Read Only mode

Malte Timmermann-2
In reply to this post by Camille Moulin-2
Hi Camille,

thanks for compiling the list and work flows :)

Some comments on removing read-only mode:

Please note that you can't remove the mode completely, but just change
the default behavior in certain situation.

I have 3 different scenarios in mind when r/o mode is used:
- File is read-only
- File is opened by an other user
- Author decided that the file shoud be opened read-only (tools /
options /security).

You can change the default behavior for the first two use cases, but you
shouldn't change it for the last one. It's used for forms and other
stuff. Also, extensions might chose to create r/o documents/views for
what ever reasons, expecting to have the current r/o behavior.

So there might be good reasons for changing the behavior in the first
two scenarios. But these are solely UX reasons, as you can't remove the
r/o mode or necessary code in the core...

Malte.





Camille Moulin wrote, On 08.10.10 09:09:

> Dear UX team,
>
> I have started listing the issues that, according to my own experience
> and info from other large scale migrations, imped the most OOo's use in
> an entreprise context.
> There is a raw list :
> http://wiki.services.openoffice.org/wiki/User:Camillem/MostProminentIssuesForEnterpriseUsage
>
> but I also started trying to identify usage profiles and basic workflows
>
> http://wiki.services.openoffice.org/wiki/User:Camillem/UserProfilesAndWorkflows
>
> As you can see, it's still in very early stage, but it already
> highlights a problem I'd like to tackle : the read only mode.
>
> Basically,it's very disorientating for users, and I can't really see the
> advantages it brings.
> So, can anyone point out use cases where it's usefull/necessary?
>
> Or can we consider starting studying the ways to remove it ? (i'm
> getting very optimistic here)
>
> Thanks,
> Camille
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

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

Reply | Threaded
Open this post in threaded view
|

Re: Removing Read Only mode

Camille Moulin-2
In reply to this post by Camille Moulin-2
Hi Malte,
----- "Malte Timmermann" <[hidden email]> a écrit :
[...]
> Please note that you can't remove the mode completely,

Well, that's a dream I won't give up easily ;-)

More seriously, I really think that code simplification is drastically needed, so every opportunity should be considered, even if it removes niche functionalities

[...]
> I have 3 different scenarios in mind when r/o mode is used:
> - File is read-only
> - File is opened by an other user
> - Author decided that the file should be opened read-only (tools /
> options /security).

Thanks, I wasn't aware of this option.

> You can change the default behavior for the first two use cases, but
> you
> shouldn't change it for the last one. It's used for forms and other
> stuff.

Well, it *can* be used for this, but is it actually used? Do we have any real life example of this?
Wouldn't the use of a protected section be an acceptable replacement?

> Also, extensions might chose to create r/o documents/views for
> what ever reasons, expecting to have the current r/o behavior.

Good point also.
I will ask on the mailing list.
 
> So there might be good reasons for changing the behavior in the first
> two scenarios. But these are solely UX reasons, as you can't remove
> the r/o mode or necessary code in the core...

If we can fix the UX problem, that would already be a great step, but I'm afraid it will cost more development effort than just removing the whole thing. (which means that it's also less likely to happen).

Thanks again for your input,
Cheers,
Camille


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

Reply | Threaded
Open this post in threaded view
|

Re: Removing Read Only mode

Irné Barnard
In reply to this post by Malte Timmermann-2
  -------- Original Message  --------
Subject: Re: [ux-discuss] Removing Read Only mode
From: Malte Timmermann <[hidden email]>
To: [hidden email]
Cc: Camille Moulin <[hidden email]>
Date: 2010-10-11 15:48:46

> I have 3 different scenarios in mind when r/o mode is used:
> - File is read-only
> - File is opened by an other user
> - Author decided that the file shoud be opened read-only (tools /
> options /security).
>
> ...
>
> So there might be good reasons for changing the behavior in the first
> two scenarios. But these are solely UX reasons, as you can't remove the
> r/o mode or necessary code in the core...
Agreed! The "normal" Read-Only should simply open the file as normal and
change the save action to a save-as, probably still have the Read-Only
displayed in the title bar though. But for files set to read-only
through security it should not allow edits (except where expressly
permitted by the author). Otherwise we'll lose the functionality of (as
your example) data-entry forms.

--
Regards Irné Barnard
Reply | Threaded
Open this post in threaded view
|

Re: Removing Read Only mode

Camille Moulin-2
In reply to this post by Camille Moulin-2

----- "Irné Barnard" <[hidden email]> a écrit :
[...]
> Agreed! The "normal" Read-Only should simply open the file as normal
> and
> change the save action to a save-as, probably still have the Read-Only
>
> displayed in the title bar though.

Agreed.

> But for files set to read-only
> through security it should not allow edits (except where expressly
> permitted by the author). Otherwise we'll lose the functionality of
> (as your example) data-entry forms.

I'm still not entirely convinced.  I just tried the equivalent functionality in MS Word, it goes like this : when you open the file you are prompted with a dialog : "This file should be open in read-only mode unless you want to modify it. Open in read only mode?"  If you click yes, the files open in the normal interface ; you just can't save it, only save it as...
So my conclusion, is that keeping the normal interface and allowing modification for files in read only, even when set in this mode via options>security..., is acceptable. I'm not saying that MS is an absolute reference, but it's just a de facto standard, so it gives an interesting opinion on the subject.

So, unless someone shows me an actual real life workflow that would be broken by such removal, I'm still in favor of removing the code to handle a specific interface and behavior for readonly.

Best,

Camille



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

Reply | Threaded
Open this post in threaded view
|

Re: Removing Read Only mode

Malte Timmermann-2
In reply to this post by Camille Moulin-2
Hi Camille,

beside the other use case I just posted on the extension list, and
Irné's valid example, see below...

[hidden email] wrote, On 11.10.10 16:39:

> Hi Malte,
> ----- "Malte Timmermann" <[hidden email]> a écrit :
> [...]
>> Please note that you can't remove the mode completely,
>
> Well, that's a dream I won't give up easily ;-)
>
> More seriously, I really think that code simplification is drastically needed, so every opportunity should be considered, even if it removes niche functionalities
>
> [...]
>> I have 3 different scenarios in mind when r/o mode is used:
>> - File is read-only
>> - File is opened by an other user
>> - Author decided that the file should be opened read-only (tools /
>> options /security).
>
> Thanks, I wasn't aware of this option.
>
>> You can change the default behavior for the first two use cases, but
>> you
>> shouldn't change it for the last one. It's used for forms and other
>> stuff.
>
> Well, it *can* be used for this, but is it actually used? Do we have any real life example of this?

We do it for certain kind of documents distributed via email or a web
server. There are two advantages:
1) People don't start modifying the document and think they still have
it after saving it. Background: Thunderbird or FireFox will store them
to %temp% before launching OOo. If you then don't recognize that you
deal with a temp file, you might make changes/corrections to it and
later simply press "Save" assuming you have the document on a safe
location. Depending on the system/application configuration, the
document might be deleted after closing the application or logout.

Well, I guess here we use it as a work around. IMHO OOo should warn the
user when storing a document to "%temp% or below (once per document,
option to disable the warning).

The better reason for using the flag is UX (hey, exactly what we want to
talk about):

2) We use the flag for documents where people are only intend to read
them, not to modify/annotate. The documents I talk about always contain
some tables, and it's really disturbing when the table tool bar, which
is floating per default, always pops up or away when navigating in the
document.

But with using the flag in the document, which we explicitly set, it's
the author's decision to present the document this way, and doesn't
affect your work on how to deal with r/o documents.

> Wouldn't the use of a protected section be an acceptable replacement?

Not sure if it works out for tables, and you also don't want to do it
for many sections.

Also it doesn't help when opening a r/o HTML form document...

>
>> Also, extensions might chose to create r/o documents/views for
>> what ever reasons, expecting to have the current r/o behavior.
>
> Good point also.
> I will ask on the mailing list.
>  
>> So there might be good reasons for changing the behavior in the first
>> two scenarios. But these are solely UX reasons, as you can't remove
>> the r/o mode or necessary code in the core...
>
> If we can fix the UX problem, that would already be a great step, but I'm afraid it will cost more development effort than just removing the whole thing. (which means that it's also less likely to happen).

"Just" removing wouldn't be enough, because you have to do the other
stuff (deal with "Save") anyway.
So actually removing the mode is an extra step, in addition to all the
stuff you need to do anyway.

For solving you particular UX issue, it's more work. Long time, removing
it would mean a little less maintenance, with the price for losing a
feature that some people might want to keep.

So I suggest to concentrate on the UX part, but leave the mode in the core.

Malte.


>
> Thanks again for your input,
> Cheers,
> Camille
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

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

Reply | Threaded
Open this post in threaded view
|

Re: Removing Read Only mode

Andreas Säger
In reply to this post by Camille Moulin-2
Am 10.10.2010 23:34, Camille Moulin wrote:

> Hi Andreas,
>
> On 10/10/2010 21:54, Andreas Säger wrote:
>> Regarding issue 89232, I'd like to say that copy&paste preserves
>> filtered rows.
>
> I know, it's a good thing, a nice progress, but in a way, that makes
> Calc's behaviour even more inconsistent and unpredictable by the user.
>
>> Issue 12666: You can even have many list ranges on the same sheet and
>> preserve all filter settings, sort orders and subtotal settings. Just
>> separate the list from other sheet content by naming it: Data>Define...
>
> I'm already aware of that, and that's what we tell users to do. But
> having to define a Database Range seems like unnecessary extra steps to
> the user. And it's hard for him to understand why some thing done a
> sheet (defining an autofilter) would affect another sheet (removing the
> autofilter).
>
>> Issue 85305: Like any other spreadsheet reference, formulas, chart
>> ranges, validation formulas, conditional formattings, list sources and
>> named references, list ranges do dynamically adjust when you insert new
>> rows into the range or directly below the range. The latter (insert
>> below) works only if Tools>Options...Calc>General is set.
> Do you mean "Expands references when new columns/row are inserted" ?
> It doesn't seem to work for me :-( (tested on OOO330m8)

It definitively works this way.

> Because actually I think it's normal that this options doesn't solve the
> problem because in this case the user doesn't insert a new row, he just
> adds data below the automatic range.
>

Well, even the other program you refer to does not update references
then. Excel can be a nightmare when it includes formulas at the bottom
of a list into the list data. This is why you can define list in Calc.

Excel may filter by the new current region next time, but SUM(A1:A99)
remains SUM(A1:A99) even when you add data below A99. Same with all
other references. Calc is more consistent in this respect. Cell ranges
grow by insertion and only by insertion.

A simple and easy to use snippet of Python code to make any of your
sheet list a little bit more like a database:
http://user.services.openoffice.org/en/forum/viewtopic.php?f=21&t=2350
You can do a sloppy selection (one cell anywhere in or below the list)
and it will insert a new row, update all references, copy down
calculated fields, take care for merged ranges and finally select the
empty cells in the new row for editing.

>> Using a most simple database solves most of the problems with dynamic
>> data ranges since a database has clearly defined row sets and Calc gets
>> a clearly defined row set from any type of database.
>
> Unfortunately, this won't fit in the real-life workflows I know about.
>

You use input forms connected to databases every day of your online life
when you visit an online shop, a forum, a "social" network.
Calc works much better with import ranges from databases. It can do
certain things that do not work with spreadsheet ranges.


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

Reply | Threaded
Open this post in threaded view
|

Re: Removing Read Only mode

Camille Moulin-2
On 11/10/2010 21:54, Andreas Säger wrote:
[...]
>> Do you mean "Expands references when new columns/row are inserted" ?
>> It doesn't seem to work for me :-( (tested on OOO330m8)
>
> It definitively works this way.
Then there must be a misunderstanding : I meant adding data and taking
them into account for filtering.
[...]
> Well, even the other program you refer to does not update references
> then. Excel can be a nightmare when it includes formulas at the bottom
> of a list into the list data. This is why you can define list in Calc.
>
> Excel may filter by the new current region next time,

Yes, that's what I was referring to.

> but SUM(A1:A99)
> remains SUM(A1:A99) even when you add data below A99. Same with all
> other references. Calc is more consistent in this respect. Cell ranges
> grow by insertion and only by insertion.

But in the situations I have encountered, the need is to update
automatically the filtered range.

> A simple and easy to use snippet of Python code to make any of your
> sheet list a little bit more like a database:
> http://user.services.openoffice.org/en/forum/viewtopic.php?f=21&t=2350
> You can do a sloppy selection (one cell anywhere in or below the list)
> and it will insert a new row, update all references, copy down
> calculated fields, take care for merged ranges and finally select the
> empty cells in the new row for editing.

I love Python so I'll have a look, but I don't think it will help for my
filtering problem.

>
>>> Using a most simple database solves most of the problems with dynamic
>>> data ranges since a database has clearly defined row sets and Calc gets
>>> a clearly defined row set from any type of database.
>>
>> Unfortunately, this won't fit in the real-life workflows I know about.
>>
>
> You use input forms connected to databases every day of your online life
> when you visit an online shop, a forum, a "social" network.

Of course. I meant spreadsheet workflows.

> Calc works much better with import ranges from databases. It can do
> certain things that do not work with spreadsheet ranges.

I don't deny that. But still, Calc's filter need the 3 basic improvement
 I mentioned if you want to access a broader audience.

Best,
Camille

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

Reply | Threaded
Open this post in threaded view
|

Re: Removing Read Only mode

Camille Moulin-2
In reply to this post by Malte Timmermann-2
On 11/10/2010 18:38, Malte Timmermann wrote:
> Hi Camille,
>
> beside the other use case I just posted on the extension list, and
> Irné's valid example, see below...
>
[...]
> We do it for certain kind of documents distributed via email or a web
> server. There are two advantages:
> 1) People don't start modifying the document and think they still have
> it after saving it.

In my target behaviour, the application would prompt a filepicker
dialogue, so they will be aware of where they will store it.

[...]
> The better reason for using the flag is UX (hey, exactly what we want to
> talk about):
>
> 2) We use the flag for documents where people are only intend to read
> them, not to modify/annotate. The documents I talk about always contain
> some tables, and it's really disturbing when the table tool bar, which
> is floating per default, always pops up or away when navigating in the
> document.

(it's a little bit OT, but I think that this toolbar should be anchored
at the bottom of the window anyway)

>
> But with using the flag in the document, which we explicitly set, it's
> the author's decision to present the document this way, and doesn't
> affect your work on how to deal with r/o documents.
>
>> Wouldn't the use of a protected section be an acceptable replacement?
>
> Not sure if it works out for tables, and you also don't want to do it
> for many sections.
>
> Also it doesn't help when opening a r/o HTML form document...
>
I think there would be further to discuss here, but the first conclusion
is that there not the consensus I thought there would be, and
considering what you write hereafter on the technical side...

[...]
>> If we can fix the UX problem, that would already be a great step, but I'm afraid it will cost more development effort than just removing the whole thing. (which means that it's also less likely to happen).
>
> "Just" removing wouldn't be enough, because you have to do the other
> stuff (deal with "Save") anyway.
> So actually removing the mode is an extra step, in addition to all the
> stuff you need to do anyway.

Hum, Ok (I thought the save part was trivial and that it would be
compensated by not having to fix the Edit File button)

> For solving you particular UX issue, it's more work. Long time, removing
> it would mean a little less maintenance, with the price for losing a
> feature that some people might want to keep.
>
> So I suggest to concentrate on the UX part, but leave the mode in the core.

Ok, we'll leave it in the core... for the moment ;-)

Best,
Camille

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

Reply | Threaded
Open this post in threaded view
|

Re: Removing Read Only mode

Andreas Säger
In reply to this post by Camille Moulin-2
Am 11.10.2010 22:18, Camille Moulin wrote:

> But in the situations I have encountered, the need is to update
> automatically the filtered range.
>

>
> I love Python so I'll have a look, but I don't think it will help for my
> filtering problem.
>

It helps you to keep your list consistent so the formulas, filters, sort
orders, charts and everything refers to the same rectangle of cells
which Excel does not do when you rely on these extra smart features. In
the end even Excel ranges grow by insertion of cells and the
automatically resized filter ranges becomes a nightmare when there is
more than the filtered range.


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

Reply | Threaded
Open this post in threaded view
|

Re: Removing Read Only mode

Hood Family
In reply to this post by Camille Moulin-2
Hi guys,

On Mon, 11 Oct 2010 17:27:22 +0200 (CEST), [hidden email] wrote:
> I just tried the equivalent
> functionality in MS Word, it goes like this : when you open the file you
> are prompted with a dialog : "This file should be open in read-only mode
> unless you want to modify it. Open in read only mode?"  If you click
yes,
> the files open in the normal interface ; you just can't save it, only
save
> it as...
> So my conclusion, is that keeping the normal interface and allowing
> modification for files in read only, even when set in this mode via
> options>security..., is acceptable. I'm not saying that MS is an
absolute
> reference, but it's just a de facto standard, so it gives an interesting
> opinion on the subject.

Testing now: if I open a read-only file in Word 2007 it is automatically
editable, and clicking "save" opens the save as dialogue.  If from the
file
open dialogue I choose to open a file as read-only, I get the same result.
I do not see the dialogue that you describe (did you test with 2007 or an
earlier version?). However I think I have seen it in the past, with 2007
as well as in earlier versions.

And I know that Word 2007 actually DOES have a read-only mode where you
can't edit the document.  In some circumstances there is an information
bar at the top of the screen that you can click on to edit the document,
but sometimes this is hidden (I think if it is hidden there is still an
arcane way to make the document editable).  
I think I've mostly seen the behaviours where the document isn't editable
in slightly unusual situations e.g. with files stored on Sharepoint.
Regardless, my conclusion is that Word is hopelessly inconsistent and
confusing and therefore an example of what needs to be avoided.

Regards,
Alister

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

Reply | Threaded
Open this post in threaded view
|

Re: Removing Read Only mode

Irné Barnard
In reply to this post by Andreas Säger
  -------- Original Message  --------
Subject: [ux-discuss] Re: Removing Read Only mode
From: Andreas Säger <[hidden email]>
To: [hidden email]
Date: 2010-10-11 21:54:40
> You can do a sloppy selection (one cell anywhere in or below the list)
> and it will insert a new row, update all references, copy down
> calculated fields, take care for merged ranges and finally select the
> empty cells in the new row for editing.
>
>
Just to clarify: Excel won't update absolute / relative addressing in
formulas unless you insert / delete a row / column within that address.
And to me that's exactly how it should work, I can see huge problems if
the program "automatically" extends such formulas without the user
having a clear indication that such has happened. You might easily find
totals showing unintended values, since very few users are going to
recheck their formulas each time they've entered some data.

However in MSO2007, if you've formatted a table inside the worksheet,
then you can add to that table by simply entering values to the right /
bottom of it. Usually this also gives a visual indication to the user
that the range has updated - since the formatting has extended to the
newly entered row/column as well. IMHO Excel 2007's tables are light
years ahead of OOo's. If we had an even remotely similar feature in
Calc, then I'd say it should work the same for table formats, i.e.: As
long as the user can see that such has happened it should be fine.

If the range did not form part of a table, then there's too many
possibilities to simply extend the range. We might have this as default,
but then (similar to Excel) showing a drop-down icon next to the
automatic change - indicate what has happened and allow the user to undo
the auto-extend. This I think would be the least disruptive, as compared
to a dialog popping up and asking "Blah blah blah ... Yes / No?"

--
Regards Irné Barnard
Reply | Threaded
Open this post in threaded view
|

Re: Removing Read Only mode

Mathias Bauer
In reply to this post by Camille Moulin-2
Hi Camille,

sorry for entering late, but I didn't find the time to read ux-discuss
in the last weeks.

On 10/11/2010 05:27 PM, [hidden email] wrote:

> So, unless someone shows me an actual real life workflow that would be broken by such removal, I'm still in favor of removing the code to handle a specific interface and behavior for readonly.

I don't like the read only mode also. But we should consider that
users/customers urged us to implement the "password to modify" in OOo.
This shows me that there is real demand for a read only mode, at least
in that context.

I think that we can get an agreement about the removal of the read only
mode in all most cases, but in case the user has selected that the file
shall be opened read only (especially if (s)he adds a password for
switching to edit mode), we should keep it.

I agree that in all other cases permitting all operations but treat the
file as "untitled document" when it is saved (perhaps with some feedback
explaining the user why this happens) will perhaps be enough to fix most
problems caused by this change.

Regards,
Mathias

--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS
Please don't reply to "[hidden email]".
I use it for the OOo lists and only rarely read other mails sent to it.

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