On 2/15/13 9:31 AM, Oliver-Rainer Wittmann wrote: > Hi, > > On 15.02.2013 00:44, Dennis E. Hamilton wrote: >> That's odd. I created a <form:text-input> field and it showed me an >> entry >> window right in the document where I put it. I could then simply type >> into >> the box that was part of my document. That is, in fact, what I expected. >> > > Hm... > I do not know <form:text-input> - I did not find such an element in ODF > 1.2. > Did you mean <form:text> or <form:formatted-text>? > >> The description of <text:text-input> in ODF 1.2 is for a situation where >> users are prompted to make an entry. > > ODF 1.2 says "A text input field is used in a user interface to prompt a > user to input text." But, it is not said, where the input has to take > place. > >> >> It sounds like you want to implement the text entry function of >> <text:text-input> the same as for <form:text-input> (but without the form >> features?). >> > > Looking from your perspective I somehow agree. > > I am currently just listening to certain customers having concerns > regarding our current UI experience.
I think exactly this is the point, the UX experience of this. IF you don't see why I can only recommend to create a document with for example 3-5 input fields and try to edit them in a intuitive and productive way. And try to navigate from one to the next field etc. I believe you will see quite fast that the current behaviour is far from usable and I have problems to accept that this was the intended behaviour in the past. Writing conform ODF is one point but an intuitive user interface is the other one. How it is realized is something else and that is what we try to figure out and what we are trying to improve. For example I can think of a field with minimal size (say at least 4 spaces but this can be changed by the user) as placeholder and when the user enters this field and start typing the size get adapted to the real size of the input. A whatever key shortcut (TBD) allows to navigate to the next input field. For fields in general I can think of a new sidebar in the future where the properties of a date field for example can be tweaked when the user enters a date field and the context switched automatically. But hey I am no UXC designer and I would let it up to other people who has a better understanding of this to define such things. It's just an idea. Juergen > > > Best regards, Oliver. > >> >> - Dennis >> >> >> -----Original Message----- >> From: Oliver-Rainer Wittmann [mailto:[email protected]] >> Sent: Thursday, February 14, 2013 01:50 >> To: [email protected]; [email protected] >> Subject: Re: [improvement idea] "in-place" editing of Input Fields in >> Writer >> >> Hi Dennis, >> >> On 06.02.2013 19:35, Dennis E. Hamilton wrote: >>> For "real" input fields, (that is, form:text elements), direct entry >> works. >>> >> >> I am not sure what you mean by '"real" input fields'. >> I am talking about the fields which are inserted into a text document in >> AOO Writer by Menu Insert - Fields - Other - Functions - Input field. >> These Input Fields are represented in ODF by the <text:text-input>. >> For these Input Fields we have no "in-place" editing in AOO Writer - as >> I have described. >> >>> I assume that the case being discussed is for conventional field values >> that >>> someone wants to edit. (Like a page number or a date field in a >>> footer.) >>> In those cases, I suppose direct entry might be useful. But there is >>> probably something needed to avoid accidental type-overs and to also >>> warn >>> that other actions might later over-write the change. Allowing for >>> that, >>> allowing type-over seems like a reasonable improvement. >>> >> >> No, I am not talking about these kind of fields. >> >> Best regards, Oliver. >> >> >> P.S.: Sorry for the long silence, again. I had got another viral flue >> which knocked me out the last days. >> >>> - Dennis >>> >>> -----Original Message----- >>> From: Oliver-Rainer Wittmann [mailto:[email protected]] >>> Sent: Wednesday, February 06, 2013 08:23 >>> To: [email protected]; [email protected] >>> Subject: [improvement idea] "in-place" editing of Input Fields in Writer >>> >>> Hi, >>> >>> recently I got notice about our (from my point of view) very >>> user-unfriendly way for editing Input Fields in Writer. >>> Currently, you can not place the cursor into an Input Field which in >>> general is shown with a grey background when Menu View - Field Shading >>> is on. If you click on the Input Field, a modal dialog pops up. In this >>> dialog you can edit the Input Field's content. On confirmation of the >>> dialog the Input Field's content is changed in the text document. To >>> edit the next Input Field you need to click on it. There is also a >>> special key shortcut - namely Shift-Ctrl-F9. This key shortcut opens the >>> Input Field content editing dialog for the first field. This time the >>> dialog has a Next button by which you can confirm your change and switch >>> directly to the next Input Field. A Previous button is not available. By >>> Murphys law the dialog hides most of the time the Input Field in the >>> text document. >>> >>> I have got the opinion that such an editing experience is bad, >>> especially, if the document is a form which makes use of a lot of Input >>> Fields to be filled by the user. >>> >>> [ ... ] >>> >>
