[SF] Removing "text with autocomplete", "textarea with autocomplete" input types?

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

[SF] Removing "text with autocomplete", "textarea with autocomplete" input types?

Yaron Koren-2
Hi everyone,

As Semantic Forms grows more complex and gains more features, I always try
to see if I can take away some complexity. In that light, I am thinking of
removing the "text with autocomplete" and "textarea with autocomplete"
input types. These two input types have been around since nearly the
beginning (though originally under different names), but they became
somewhat obsolete when the "tokens" input types was added in 2014. Between
the two of them, "tokens" and "combobox" (added in 2010) can essentially do
everything that "text with autocomplete" and "textarea with autocomplete"
do, but better:

- both make it clearer visually that there is autocompletion for that field
- the autocompletion for both handles accented characters and (I believe)
non-Latin characters in general better than the "... with autocomplete"
inputs
- both allow for the "values from external data" parameter, which allows
for some interesting things like setting an image for each value, while the
"... with autocomplete" input types do not
- the "combobox" input type includes a nice dropdown to let users see the
set of possible values at the beginning
- the "tokens" input type automatically resizes itself to display its
current set of values, which the "... with autocomplete" input types do not
- "tokenizing" values is just a nice way of dealing with a list of values -
it has become a popular interface choice for that reason.

In addition, there are the standard reasons for removing less-useful
functionality: having fewer features means less work for both developers
and users.

Nonetheless, there may be valid reasons for keeping one or both of these
input types. If anyone has any thoughts on the matter, I'd be curious to
hear it.

-Yaron

--
WikiWorks · MediaWiki Consulting · http://wikiworks.com
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
Reply | Threaded
Open this post in threaded view
|

Re: [SF] Removing "text with autocomplete", "textarea with autocomplete" input types?

kghbln
Heiya Yaron,

I actually use both input types quite a lot and so far "tokens" and
"combobox" not at all. Perhaps it is just a matter of habit.

When thinking about "textarea with autocomplete" I would not like to
loose the ability to display a textarea (= specifying rows) from the
start in contrast to just a line which automatically expands. The reason
for this is that people should see and intuitively figure that more may
be filled into the field. This appears to be quite an important reason
for me personally. I do not think that token allows for this.

Fields with "texarea with autocomplete" actually do resize with the
"autogrow" option.

One reason why I am so far not using "tokens" in comparison to "text
with autocomplete" is that one actually sees that it is a token. It is
probably a matter of fiddling around with CSS to get the look and feel
more homogeneous and avoid the button style appearance of tokens.

Fields using "text with autocomplete" also allow for a drop-down like
view of possible values so I cannot currently recall the advantage of
"combobox" though I remember there was one. Hmm ... probably it was the
number of values to choose: The more you have the more likely you are to
use "combobox".

These are basically my fly-by thoughts.

Cheers Karsten

Am 22.04.2016 um 07:16 schrieb Yaron Koren:

> Hi everyone,
>
> As Semantic Forms grows more complex and gains more features, I always try
> to see if I can take away some complexity. In that light, I am thinking of
> removing the "text with autocomplete" and "textarea with autocomplete"
> input types. These two input types have been around since nearly the
> beginning (though originally under different names), but they became
> somewhat obsolete when the "tokens" input types was added in 2014. Between
> the two of them, "tokens" and "combobox" (added in 2010) can essentially do
> everything that "text with autocomplete" and "textarea with autocomplete"
> do, but better:
>
> - both make it clearer visually that there is autocompletion for that field
> - the autocompletion for both handles accented characters and (I believe)
> non-Latin characters in general better than the "... with autocomplete"
> inputs
> - both allow for the "values from external data" parameter, which allows
> for some interesting things like setting an image for each value, while the
> "... with autocomplete" input types do not
> - the "combobox" input type includes a nice dropdown to let users see the
> set of possible values at the beginning
> - the "tokens" input type automatically resizes itself to display its
> current set of values, which the "... with autocomplete" input types do not
> - "tokenizing" values is just a nice way of dealing with a list of values -
> it has become a popular interface choice for that reason.
>
> In addition, there are the standard reasons for removing less-useful
> functionality: having fewer features means less work for both developers
> and users.
>
> Nonetheless, there may be valid reasons for keeping one or both of these
> input types. If anyone has any thoughts on the matter, I'd be curious to
> hear it.
>
> -Yaron
>

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
Reply | Threaded
Open this post in threaded view
|

Re: [SF] Removing "text with autocomplete", "textarea with autocomplete" input types?

Tobias Oetterer
In reply to this post by Yaron Koren-2
Hi

Normally, I use tokens and combobox when working with autocomplete/values from <..>. The only instance I return to "text with autocomplete" is the usecase "image upload field". Frankly that is, because I don't know if combobox allows for the parameter "uploadable" and at the time I didn't take the time to try it out...

Why I normally use combobox and tokens? They were already around when I started using Semantic Forms, they do exactly what I want them to and they look way more fancy than text fields! :)

Have a nice day everyone!

Tobias Oetterer

--
If this email is rather brief, it is not meant to be impolite but to respect your time.
http://five.sentenc.es
No trees were killed to send this message, but a large number of electrons were terribly inconvenienced

University of Paderborn
Zentrum IMT
Warburger Straße 100
33098 Paderborn

Office: N5.341
Phone: 05251/60-2194
Internet: http://imt.uni-paderborn.de
-----Ursprüngliche Nachricht-----
Von: Yaron Koren [mailto:[hidden email]]
Gesendet: Freitag, 22. April 2016 07:16
An: Semantic MediaWiki users
Betreff: [Semediawiki-user] [SF] Removing "text with autocomplete", "textarea with autocomplete" input types?

Hi everyone,

As Semantic Forms grows more complex and gains more features, I always try to see if I can take away some complexity. In that light, I am thinking of removing the "text with autocomplete" and "textarea with autocomplete"
input types. These two input types have been around since nearly the beginning (though originally under different names), but they became somewhat obsolete when the "tokens" input types was added in 2014. Between the two of them, "tokens" and "combobox" (added in 2010) can essentially do everything that "text with autocomplete" and "textarea with autocomplete"
do, but better:

- both make it clearer visually that there is autocompletion for that field
- the autocompletion for both handles accented characters and (I believe) non-Latin characters in general better than the "... with autocomplete"
inputs
- both allow for the "values from external data" parameter, which allows for some interesting things like setting an image for each value, while the "... with autocomplete" input types do not
- the "combobox" input type includes a nice dropdown to let users see the set of possible values at the beginning
- the "tokens" input type automatically resizes itself to display its current set of values, which the "... with autocomplete" input types do not
- "tokenizing" values is just a nice way of dealing with a list of values - it has become a popular interface choice for that reason.

In addition, there are the standard reasons for removing less-useful
functionality: having fewer features means less work for both developers and users.

Nonetheless, there may be valid reasons for keeping one or both of these input types. If anyone has any thoughts on the matter, I'd be curious to hear it.

-Yaron

--
WikiWorks · MediaWiki Consulting · http://wikiworks.com
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
Reply | Threaded
Open this post in threaded view
|

Re: [SF] Removing "text with autocomplete", "textarea with autocomplete" input types?

Tiago Ferreira
In reply to this post by kghbln
Hi,

Just my 2 cents:

The ability to specify rows makes a lot of sense from a regular user's
perspective. Having tokens with the ability to set the field's size would
cover 99% of the "textarea with autocomplete" use cases.

Tiago Ferreira


On Fri, Apr 22, 2016 at 10:09 AM, kghbln <[hidden email]> wrote:

> Heiya Yaron,
>
> I actually use both input types quite a lot and so far "tokens" and
> "combobox" not at all. Perhaps it is just a matter of habit.
>
> When thinking about "textarea with autocomplete" I would not like to
> loose the ability to display a textarea (= specifying rows) from the
> start in contrast to just a line which automatically expands. The reason
> for this is that people should see and intuitively figure that more may
> be filled into the field. This appears to be quite an important reason
> for me personally. I do not think that token allows for this.
>
> Fields with "texarea with autocomplete" actually do resize with the
> "autogrow" option.
>
> One reason why I am so far not using "tokens" in comparison to "text
> with autocomplete" is that one actually sees that it is a token. It is
> probably a matter of fiddling around with CSS to get the look and feel
> more homogeneous and avoid the button style appearance of tokens.
>
> Fields using "text with autocomplete" also allow for a drop-down like
> view of possible values so I cannot currently recall the advantage of
> "combobox" though I remember there was one. Hmm ... probably it was the
> number of values to choose: The more you have the more likely you are to
> use "combobox".
>
> These are basically my fly-by thoughts.
>
> Cheers Karsten
>
> Am 22.04.2016 um 07:16 schrieb Yaron Koren:
> > Hi everyone,
> >
> > As Semantic Forms grows more complex and gains more features, I always
> try
> > to see if I can take away some complexity. In that light, I am thinking
> of
> > removing the "text with autocomplete" and "textarea with autocomplete"
> > input types. These two input types have been around since nearly the
> > beginning (though originally under different names), but they became
> > somewhat obsolete when the "tokens" input types was added in 2014.
> Between
> > the two of them, "tokens" and "combobox" (added in 2010) can essentially
> do
> > everything that "text with autocomplete" and "textarea with autocomplete"
> > do, but better:
> >
> > - both make it clearer visually that there is autocompletion for that
> field
> > - the autocompletion for both handles accented characters and (I believe)
> > non-Latin characters in general better than the "... with autocomplete"
> > inputs
> > - both allow for the "values from external data" parameter, which allows
> > for some interesting things like setting an image for each value, while
> the
> > "... with autocomplete" input types do not
> > - the "combobox" input type includes a nice dropdown to let users see the
> > set of possible values at the beginning
> > - the "tokens" input type automatically resizes itself to display its
> > current set of values, which the "... with autocomplete" input types do
> not
> > - "tokenizing" values is just a nice way of dealing with a list of
> values -
> > it has become a popular interface choice for that reason.
> >
> > In addition, there are the standard reasons for removing less-useful
> > functionality: having fewer features means less work for both developers
> > and users.
> >
> > Nonetheless, there may be valid reasons for keeping one or both of these
> > input types. If anyone has any thoughts on the matter, I'd be curious to
> > hear it.
> >
> > -Yaron
> >
>
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> Semediawiki-user mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
>
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
Reply | Threaded
Open this post in threaded view
|

Re: [SF] Removing "text with autocomplete", "textarea with autocomplete" input types?

Phil Legault-2
In reply to this post by Yaron Koren-2
I'm using a form with 4 properties that use "text with autocomplete" I change them all to use tokens.All of the fields show the tokens, 2 of the fields when I click on them show the drop down list and 2 of them don't. They all worked with "text with autocomplete"
What should I look for that would cause this problem?
Thanks,Phil

> Date: Thu, 21 Apr 2016 22:16:27 -0700
> From: [hidden email]
> To: [hidden email]
> Subject: [Semediawiki-user] [SF] Removing "text with autocomplete", "textarea with autocomplete" input types?
>
> Hi everyone,
>
> As Semantic Forms grows more complex and gains more features, I always try
> to see if I can take away some complexity. In that light, I am thinking of
> removing the "text with autocomplete" and "textarea with autocomplete"
> input types. These two input types have been around since nearly the
> beginning (though originally under different names), but they became
> somewhat obsolete when the "tokens" input types was added in 2014. Between
> the two of them, "tokens" and "combobox" (added in 2010) can essentially do
> everything that "text with autocomplete" and "textarea with autocomplete"
> do, but better:
>
> - both make it clearer visually that there is autocompletion for that field
> - the autocompletion for both handles accented characters and (I believe)
> non-Latin characters in general better than the "... with autocomplete"
> inputs
> - both allow for the "values from external data" parameter, which allows
> for some interesting things like setting an image for each value, while the
> "... with autocomplete" input types do not
> - the "combobox" input type includes a nice dropdown to let users see the
> set of possible values at the beginning
> - the "tokens" input type automatically resizes itself to display its
> current set of values, which the "... with autocomplete" input types do not
> - "tokenizing" values is just a nice way of dealing with a list of values -
> it has become a popular interface choice for that reason.
>
> In addition, there are the standard reasons for removing less-useful
> functionality: having fewer features means less work for both developers
> and users.
>
> Nonetheless, there may be valid reasons for keeping one or both of these
> input types. If anyone has any thoughts on the matter, I'd be curious to
> hear it.
>
> -Yaron
>
> --
> WikiWorks · MediaWiki Consulting · http://wikiworks.com
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> Semediawiki-user mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
     
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
Reply | Threaded
Open this post in threaded view
|

Re: [SF] Removing "text with autocomplete", "textarea with autocomplete" input types?

Jaider Andrade Ferreira
In reply to this post by Yaron Koren-2
Hi,

I like (and currently I am using) the "text with autocomplete" and the
"textarea with autocomplete" input types because I think it's more easy to
edit an already saved value than the "tokens" or "combobox" input types.
I mean, to insert a letter in the middle of the previous value, or to
select a value to copy and paste among fields is easy with "text with
autocomplete" and the "textarea with autocomplete" but not so easy with
"tokens" or "combobox".
I do agree that "tokens" and "combobox" are really nice input types with a
lot of functionality, but "text with autocomplete" and the "textarea with
autocomplete" have their importance, too.


On Fri, Apr 22, 2016 at 2:16 AM, Yaron Koren <[hidden email]> wrote:

> Hi everyone,
>
> As Semantic Forms grows more complex and gains more features, I always try
> to see if I can take away some complexity. In that light, I am thinking of
> removing the "text with autocomplete" and "textarea with autocomplete"
> input types. These two input types have been around since nearly the
> beginning (though originally under different names), but they became
> somewhat obsolete when the "tokens" input types was added in 2014. Between
> the two of them, "tokens" and "combobox" (added in 2010) can essentially do
> everything that "text with autocomplete" and "textarea with autocomplete"
> do, but better:
>
> - both make it clearer visually that there is autocompletion for that field
> - the autocompletion for both handles accented characters and (I believe)
> non-Latin characters in general better than the "... with autocomplete"
> inputs
> - both allow for the "values from external data" parameter, which allows
> for some interesting things like setting an image for each value, while the
> "... with autocomplete" input types do not
> - the "combobox" input type includes a nice dropdown to let users see the
> set of possible values at the beginning
> - the "tokens" input type automatically resizes itself to display its
> current set of values, which the "... with autocomplete" input types do not
> - "tokenizing" values is just a nice way of dealing with a list of values -
> it has become a popular interface choice for that reason.
>
> In addition, there are the standard reasons for removing less-useful
> functionality: having fewer features means less work for both developers
> and users.
>
> Nonetheless, there may be valid reasons for keeping one or both of these
> input types. If anyone has any thoughts on the matter, I'd be curious to
> hear it.
>
> -Yaron
>
> --
> WikiWorks · MediaWiki Consulting · http://wikiworks.com
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> Semediawiki-user mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
>



--
Jaider
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
Reply | Threaded
Open this post in threaded view
|

Re: [SF] Removing "text with autocomplete", "textarea with autocomplete" input types?

Yaron Koren-2
Hi everyone,

Thanks for all your responses. Clearly people like "text[area] with
autocomplete" more than I thought they did! It's good to get this kind of
feedback in general.

Phil - issues like this seem like they should go into a separate thread;
I'm trying to keep this one focused. But I assume that, if there are any
bugs with "tokens" or "combobox", they can be fixed.

Tobias - your guess was right; neither "tokens" nor "combobox" support the
"uploadable" feature. (I just checked, and actually neither does "textarea
with autocomplete", though I think it used to. That seems like something
that should be added, if that's possible, regardless of what else is done.

Karsten - "combobox" has a dropdown at the very beginning, before the user
has typed anything, which I don't think you can do with "text with
autocomplete". I might be wrong, though.

Karsten and Tiago - there might indeed be an advantage in having the
"tokens" input start out with a height greater than one row, to make it
clearer that it can expand vertically. Hopefully there's an easy way to do
that.

Karsten and Jaider - your comments about preferring the look and feel of
"standard" autocompletion of a list of values vs. a tokenized input are the
most intriguing, because I was sure that everyone preferred having tokens.
I guess that Karsten, you're just talking about the look, and Jaider,
you're just talking about the feel. :) Karsten - what's the issue with
values looking like buttons?

Jaider - it's true that values can't be changed, which can be annoying. It
would be better if the tokens had the behavior that they have in Gmail,
where double-clicking on a token "un-tokenizes" it, turning it back into
text that can then be modified or copied. I hadn't thought about that until
now. Maybe, again, this is something that can be changed.

-Yaron

On Fri, Apr 22, 2016 at 8:25 AM, Jaider Andrade Ferreira <[hidden email]
> wrote:

> Hi,
>
> I like (and currently I am using) the "text with autocomplete" and the
> "textarea with autocomplete" input types because I think it's more easy to
> edit an already saved value than the "tokens" or "combobox" input types.
> I mean, to insert a letter in the middle of the previous value, or to
> select a value to copy and paste among fields is easy with "text with
> autocomplete" and the "textarea with autocomplete" but not so easy with
> "tokens" or "combobox".
> I do agree that "tokens" and "combobox" are really nice input types with a
> lot of functionality, but "text with autocomplete" and the "textarea with
> autocomplete" have their importance, too.
>
>
> On Fri, Apr 22, 2016 at 2:16 AM, Yaron Koren <[hidden email]> wrote:
>
>> Hi everyone,
>>
>> As Semantic Forms grows more complex and gains more features, I always try
>> to see if I can take away some complexity. In that light, I am thinking of
>> removing the "text with autocomplete" and "textarea with autocomplete"
>> input types. These two input types have been around since nearly the
>> beginning (though originally under different names), but they became
>> somewhat obsolete when the "tokens" input types was added in 2014. Between
>> the two of them, "tokens" and "combobox" (added in 2010) can essentially
>> do
>> everything that "text with autocomplete" and "textarea with autocomplete"
>> do, but better:
>>
>> - both make it clearer visually that there is autocompletion for that
>> field
>> - the autocompletion for both handles accented characters and (I believe)
>> non-Latin characters in general better than the "... with autocomplete"
>> inputs
>> - both allow for the "values from external data" parameter, which allows
>> for some interesting things like setting an image for each value, while
>> the
>> "... with autocomplete" input types do not
>> - the "combobox" input type includes a nice dropdown to let users see the
>> set of possible values at the beginning
>> - the "tokens" input type automatically resizes itself to display its
>> current set of values, which the "... with autocomplete" input types do
>> not
>> - "tokenizing" values is just a nice way of dealing with a list of values
>> -
>> it has become a popular interface choice for that reason.
>>
>> In addition, there are the standard reasons for removing less-useful
>> functionality: having fewer features means less work for both developers
>> and users.
>>
>> Nonetheless, there may be valid reasons for keeping one or both of these
>> input types. If anyone has any thoughts on the matter, I'd be curious to
>> hear it.
>>
>> -Yaron
>>
>> --
>> WikiWorks · MediaWiki Consulting · http://wikiworks.com
>>
>> ------------------------------------------------------------------------------
>> Find and fix application performance issues faster with Applications
>> Manager
>> Applications Manager provides deep performance insights into multiple
>> tiers of
>> your business applications. It resolves application problems quickly and
>> reduces your MTTR. Get your free trial!
>> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
>> _______________________________________________
>> Semediawiki-user mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
>>
>
>
>
> --
> Jaider
>



--
WikiWorks · MediaWiki Consulting · http://wikiworks.com
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
Reply | Threaded
Open this post in threaded view
|

Re: [SF] Removing "text with autocomplete", "textarea with autocomplete" input types?

Fannon
Hello!

my 2 cents:

I don't use text[area] with autocomplete at all and prefer the modern look
and feel of select2 token / combox.

I have one issue with the newer select2 widgets, though: You need to press
ENTER (or semicolon) to actually insert the value. If you change the focus
after you've typed you will lose the content if you haven't done this.
This differs from the behaviour of all other widgets. And it's also
somewhat uncomfortable, as in a form ENTER usually triggers the form
submission.

Best,
Simon

2016-04-22 20:21 GMT+02:00 Yaron Koren <[hidden email]>:

> Hi everyone,
>
> Thanks for all your responses. Clearly people like "text[area] with
> autocomplete" more than I thought they did! It's good to get this kind of
> feedback in general.
>
> Phil - issues like this seem like they should go into a separate thread;
> I'm trying to keep this one focused. But I assume that, if there are any
> bugs with "tokens" or "combobox", they can be fixed.
>
> Tobias - your guess was right; neither "tokens" nor "combobox" support the
> "uploadable" feature. (I just checked, and actually neither does "textarea
> with autocomplete", though I think it used to. That seems like something
> that should be added, if that's possible, regardless of what else is done.
>
> Karsten - "combobox" has a dropdown at the very beginning, before the user
> has typed anything, which I don't think you can do with "text with
> autocomplete". I might be wrong, though.
>
> Karsten and Tiago - there might indeed be an advantage in having the
> "tokens" input start out with a height greater than one row, to make it
> clearer that it can expand vertically. Hopefully there's an easy way to do
> that.
>
> Karsten and Jaider - your comments about preferring the look and feel of
> "standard" autocompletion of a list of values vs. a tokenized input are the
> most intriguing, because I was sure that everyone preferred having tokens.
> I guess that Karsten, you're just talking about the look, and Jaider,
> you're just talking about the feel. :) Karsten - what's the issue with
> values looking like buttons?
>
> Jaider - it's true that values can't be changed, which can be annoying. It
> would be better if the tokens had the behavior that they have in Gmail,
> where double-clicking on a token "un-tokenizes" it, turning it back into
> text that can then be modified or copied. I hadn't thought about that until
> now. Maybe, again, this is something that can be changed.
>
> -Yaron
>
> On Fri, Apr 22, 2016 at 8:25 AM, Jaider Andrade Ferreira <
> [hidden email]
> > wrote:
>
> > Hi,
> >
> > I like (and currently I am using) the "text with autocomplete" and the
> > "textarea with autocomplete" input types because I think it's more easy
> to
> > edit an already saved value than the "tokens" or "combobox" input types.
> > I mean, to insert a letter in the middle of the previous value, or to
> > select a value to copy and paste among fields is easy with "text with
> > autocomplete" and the "textarea with autocomplete" but not so easy with
> > "tokens" or "combobox".
> > I do agree that "tokens" and "combobox" are really nice input types with
> a
> > lot of functionality, but "text with autocomplete" and the "textarea with
> > autocomplete" have their importance, too.
> >
> >
> > On Fri, Apr 22, 2016 at 2:16 AM, Yaron Koren <[hidden email]>
> wrote:
> >
> >> Hi everyone,
> >>
> >> As Semantic Forms grows more complex and gains more features, I always
> try
> >> to see if I can take away some complexity. In that light, I am thinking
> of
> >> removing the "text with autocomplete" and "textarea with autocomplete"
> >> input types. These two input types have been around since nearly the
> >> beginning (though originally under different names), but they became
> >> somewhat obsolete when the "tokens" input types was added in 2014.
> Between
> >> the two of them, "tokens" and "combobox" (added in 2010) can essentially
> >> do
> >> everything that "text with autocomplete" and "textarea with
> autocomplete"
> >> do, but better:
> >>
> >> - both make it clearer visually that there is autocompletion for that
> >> field
> >> - the autocompletion for both handles accented characters and (I
> believe)
> >> non-Latin characters in general better than the "... with autocomplete"
> >> inputs
> >> - both allow for the "values from external data" parameter, which allows
> >> for some interesting things like setting an image for each value, while
> >> the
> >> "... with autocomplete" input types do not
> >> - the "combobox" input type includes a nice dropdown to let users see
> the
> >> set of possible values at the beginning
> >> - the "tokens" input type automatically resizes itself to display its
> >> current set of values, which the "... with autocomplete" input types do
> >> not
> >> - "tokenizing" values is just a nice way of dealing with a list of
> values
> >> -
> >> it has become a popular interface choice for that reason.
> >>
> >> In addition, there are the standard reasons for removing less-useful
> >> functionality: having fewer features means less work for both developers
> >> and users.
> >>
> >> Nonetheless, there may be valid reasons for keeping one or both of these
> >> input types. If anyone has any thoughts on the matter, I'd be curious to
> >> hear it.
> >>
> >> -Yaron
> >>
> >> --
> >> WikiWorks · MediaWiki Consulting · http://wikiworks.com
> >>
> >>
> ------------------------------------------------------------------------------
> >> Find and fix application performance issues faster with Applications
> >> Manager
> >> Applications Manager provides deep performance insights into multiple
> >> tiers of
> >> your business applications. It resolves application problems quickly and
> >> reduces your MTTR. Get your free trial!
> >> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> >> _______________________________________________
> >> Semediawiki-user mailing list
> >> [hidden email]
> >> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
> >>
> >
> >
> >
> > --
> > Jaider
> >
>
>
>
> --
> WikiWorks · MediaWiki Consulting · http://wikiworks.com
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> Semediawiki-user mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
>
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
Reply | Threaded
Open this post in threaded view
|

Re: [SF] Removing "text with autocomplete", "textarea with autocomplete" input types?

Ad Strack van Schijndel
In reply to this post by Yaron Koren-2
Hi Yaron,

I use textarea with autocomplete in some cases where you can have many values (> 100) in the field. Would that be a problem with tokens?

The 'un-tokenizing' feature would be nice!

Ad


> On 22 Apr 2016, at 20:21, Yaron Koren <[hidden email]> wrote:
>
> Hi everyone,
>
> Thanks for all your responses. Clearly people like "text[area] with
> autocomplete" more than I thought they did! It's good to get this kind of
> feedback in general.
>
> Phil - issues like this seem like they should go into a separate thread;
> I'm trying to keep this one focused. But I assume that, if there are any
> bugs with "tokens" or "combobox", they can be fixed.
>
> Tobias - your guess was right; neither "tokens" nor "combobox" support the
> "uploadable" feature. (I just checked, and actually neither does "textarea
> with autocomplete", though I think it used to. That seems like something
> that should be added, if that's possible, regardless of what else is done.
>
> Karsten - "combobox" has a dropdown at the very beginning, before the user
> has typed anything, which I don't think you can do with "text with
> autocomplete". I might be wrong, though.
>
> Karsten and Tiago - there might indeed be an advantage in having the
> "tokens" input start out with a height greater than one row, to make it
> clearer that it can expand vertically. Hopefully there's an easy way to do
> that.
>
> Karsten and Jaider - your comments about preferring the look and feel of
> "standard" autocompletion of a list of values vs. a tokenized input are the
> most intriguing, because I was sure that everyone preferred having tokens.
> I guess that Karsten, you're just talking about the look, and Jaider,
> you're just talking about the feel. :) Karsten - what's the issue with
> values looking like buttons?
>
> Jaider - it's true that values can't be changed, which can be annoying. It
> would be better if the tokens had the behavior that they have in Gmail,
> where double-clicking on a token "un-tokenizes" it, turning it back into
> text that can then be modified or copied. I hadn't thought about that until
> now. Maybe, again, this is something that can be changed.
>
> -Yaron
>
> On Fri, Apr 22, 2016 at 8:25 AM, Jaider Andrade Ferreira <[hidden email] <mailto:[hidden email]>
>> wrote:
>
>> Hi,
>>
>> I like (and currently I am using) the "text with autocomplete" and the
>> "textarea with autocomplete" input types because I think it's more easy to
>> edit an already saved value than the "tokens" or "combobox" input types.
>> I mean, to insert a letter in the middle of the previous value, or to
>> select a value to copy and paste among fields is easy with "text with
>> autocomplete" and the "textarea with autocomplete" but not so easy with
>> "tokens" or "combobox".
>> I do agree that "tokens" and "combobox" are really nice input types with a
>> lot of functionality, but "text with autocomplete" and the "textarea with
>> autocomplete" have their importance, too.
>>
>>
>> On Fri, Apr 22, 2016 at 2:16 AM, Yaron Koren <[hidden email]> wrote:
>>
>>> Hi everyone,
>>>
>>> As Semantic Forms grows more complex and gains more features, I always try
>>> to see if I can take away some complexity. In that light, I am thinking of
>>> removing the "text with autocomplete" and "textarea with autocomplete"
>>> input types. These two input types have been around since nearly the
>>> beginning (though originally under different names), but they became
>>> somewhat obsolete when the "tokens" input types was added in 2014. Between
>>> the two of them, "tokens" and "combobox" (added in 2010) can essentially
>>> do
>>> everything that "text with autocomplete" and "textarea with autocomplete"
>>> do, but better:
>>>
>>> - both make it clearer visually that there is autocompletion for that
>>> field
>>> - the autocompletion for both handles accented characters and (I believe)
>>> non-Latin characters in general better than the "... with autocomplete"
>>> inputs
>>> - both allow for the "values from external data" parameter, which allows
>>> for some interesting things like setting an image for each value, while
>>> the
>>> "... with autocomplete" input types do not
>>> - the "combobox" input type includes a nice dropdown to let users see the
>>> set of possible values at the beginning
>>> - the "tokens" input type automatically resizes itself to display its
>>> current set of values, which the "... with autocomplete" input types do
>>> not
>>> - "tokenizing" values is just a nice way of dealing with a list of values
>>> -
>>> it has become a popular interface choice for that reason.
>>>
>>> In addition, there are the standard reasons for removing less-useful
>>> functionality: having fewer features means less work for both developers
>>> and users.
>>>
>>> Nonetheless, there may be valid reasons for keeping one or both of these
>>> input types. If anyone has any thoughts on the matter, I'd be curious to
>>> hear it.
>>>
>>> -Yaron
>>>
>>> --
>>> WikiWorks · MediaWiki Consulting · http://wikiworks.com
>>>
>>> ------------------------------------------------------------------------------
>>> Find and fix application performance issues faster with Applications
>>> Manager
>>> Applications Manager provides deep performance insights into multiple
>>> tiers of
>>> your business applications. It resolves application problems quickly and
>>> reduces your MTTR. Get your free trial!
>>> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
>>> _______________________________________________
>>> Semediawiki-user mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
>>>
>>
>>
>>
>> --
>> Jaider
>>
>
>
>
> --
> WikiWorks · MediaWiki Consulting · http://wikiworks.com <http://wikiworks.com/>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> Semediawiki-user mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/semediawiki-user

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
Reply | Threaded
Open this post in threaded view
|

Re: [SF] Removing "text with autocomplete", "textarea with autocomplete" input types?

Ad Strack van Schijndel
In reply to this post by Yaron Koren-2
Hi Yaron,

I use textarea with autocomplete in some cases where you can have many values (> 100) in the field. Would that be a problem with tokens?

The 'un-tokenizing' feature would be nice!

Ad


> On 22 Apr 2016, at 20:21, Yaron Koren <[hidden email] <mailto:[hidden email]>> wrote:
>
> Hi everyone,
>
> Thanks for all your responses. Clearly people like "text[area] with
> autocomplete" more than I thought they did! It's good to get this kind of
> feedback in general.
>
> Phil - issues like this seem like they should go into a separate thread;
> I'm trying to keep this one focused. But I assume that, if there are any
> bugs with "tokens" or "combobox", they can be fixed.
>
> Tobias - your guess was right; neither "tokens" nor "combobox" support the
> "uploadable" feature. (I just checked, and actually neither does "textarea
> with autocomplete", though I think it used to. That seems like something
> that should be added, if that's possible, regardless of what else is done.
>
> Karsten - "combobox" has a dropdown at the very beginning, before the user
> has typed anything, which I don't think you can do with "text with
> autocomplete". I might be wrong, though.
>
> Karsten and Tiago - there might indeed be an advantage in having the
> "tokens" input start out with a height greater than one row, to make it
> clearer that it can expand vertically. Hopefully there's an easy way to do
> that.
>
> Karsten and Jaider - your comments about preferring the look and feel of
> "standard" autocompletion of a list of values vs. a tokenized input are the
> most intriguing, because I was sure that everyone preferred having tokens.
> I guess that Karsten, you're just talking about the look, and Jaider,
> you're just talking about the feel. :) Karsten - what's the issue with
> values looking like buttons?
>
> Jaider - it's true that values can't be changed, which can be annoying. It
> would be better if the tokens had the behavior that they have in Gmail,
> where double-clicking on a token "un-tokenizes" it, turning it back into
> text that can then be modified or copied. I hadn't thought about that until
> now. Maybe, again, this is something that can be changed.
>
> -Yaron
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
Reply | Threaded
Open this post in threaded view
|

Re: [SF] Removing "text with autocomplete", "textarea with autocomplete" input types?

Sintonen Henri
In reply to this post by Yaron Koren-2
Hi!

I use text/textarea with autocomplete quite often, since the forms I make are originally Word documents that I try to imitate. To make the transition as smooth as possible for my users I try to match the form as closely as I can to the document, so I try to avoid tokens/comboboxes if I can (although I still use them). As others have said the biggest reasons are difficulty in editing the text and needing to use Enter for each token. I end up writing instructions on each form on how to use them, usually on the placeholder for the field, since it may be hard to differentiate the type of the field before interacting with it, especially for someone filling the form for the first time.

Maybe we could have a parameter for the characters that separate each token? When listing countries a comma would usually suffice instead of / alongside Enter (while someone might want to write e.g. "Korea, The Republic of" I think the dropdown listing would help with that), and a semicolon definitely would.

Henri


-----Original Message-----
From: Yaron Koren [mailto:[hidden email]]
Sent: 22. huhtikuuta 2016 8:16
To: Semantic MediaWiki users
Subject: [Semediawiki-user] [SF] Removing "text with autocomplete", "textarea with autocomplete" input types?

Hi everyone,

As Semantic Forms grows more complex and gains more features, I always try to see if I can take away some complexity. In that light, I am thinking of removing the "text with autocomplete" and "textarea with autocomplete"
input types. These two input types have been around since nearly the beginning (though originally under different names), but they became somewhat obsolete when the "tokens" input types was added in 2014. Between the two of them, "tokens" and "combobox" (added in 2010) can essentially do everything that "text with autocomplete" and "textarea with autocomplete"
do, but better:

- both make it clearer visually that there is autocompletion for that field
- the autocompletion for both handles accented characters and (I believe) non-Latin characters in general better than the "... with autocomplete"
inputs
- both allow for the "values from external data" parameter, which allows for some interesting things like setting an image for each value, while the "... with autocomplete" input types do not
- the "combobox" input type includes a nice dropdown to let users see the set of possible values at the beginning
- the "tokens" input type automatically resizes itself to display its current set of values, which the "... with autocomplete" input types do not
- "tokenizing" values is just a nice way of dealing with a list of values - it has become a popular interface choice for that reason.

In addition, there are the standard reasons for removing less-useful
functionality: having fewer features means less work for both developers and users.

Nonetheless, there may be valid reasons for keeping one or both of these input types. If anyone has any thoughts on the matter, I'd be curious to hear it.

-Yaron

--
WikiWorks · MediaWiki Consulting · http://wikiworks.com
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
Reply | Threaded
Open this post in threaded view
|

Re: [SF] Removing "text with autocomplete", "textarea with autocomplete" input types?

Yaron Koren-2
Hi,

Thanks to everyone for the additional comments, and I look forward to
hearing anything else people have to say.

Simon, Henri - it's true that the selection process with the Select2 inputs
is kind of annoying; it would be better if the value showed up in the input
when you get to it with the arrow key in the dropdown, as happens with the
".... with autocomplete" inputs. (I hope that made sense.)

Ad - I think "tokens" handles a large number of values just fine.

So, I think it's clear at this point that the "text[area] with
autocomplete" inputs, i.e. the inputs that use jQuery UI, are still
necessary; which makes this more of a comment thread about "issues people
have with tokens". :)

To summarize the comments, it seems to me that the necessary changes that
would have to be made, before any input types can really be removed, are,
in rough order from most to least necessary:

- Allow the tokens input to be taller when starting out, to make it clearer
that it can expand
- Have the tokens input un-tokenize values when they are double-clicked
- Have both input types support the "uploadable" parameter
- In some way, let users select a value in these input types without either
hitting "Enter" or clicking a mouse.

Karsten -  I'm also still curious about your desire to have the tokens not
look like buttons; but maybe that's a minor thing.

By the way, if there's a JavaScript autocompletion library that already
offers all of these features, I would be happy to consider switching to
that one; I haven't found one. Tokenized autocompletion (also referred to
as "tag-style autocompletion", and similar) is not supported in general by
a lot of JS libraries, despite its obvious (in my view) advantages.
Hopefully that will change in the future.

Also, I looked up the un-tokenizing thing in the Select2 forum, and indeed
this is a popular request; see here:

https://github.com/select2/select2/issues/116

If you scroll down to the bottom, this issue was closed in 2014 in what I
would consider an unsatisfactory way: they added the ability to un-tokenize
only the last value in the set - by hitting the "backspace" key - and
considered the issue resolved. But earlier in that thread a few people
offer JS patches that claim to do what we've been talking about, with the
double-clicking; hopefully one of those can be added here.

-Yaron

--
WikiWorks · MediaWiki Consulting · http://wikiworks.com
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
Reply | Threaded
Open this post in threaded view
|

Re: [SF] Removing "text with autocomplete", "textarea with autocomplete" input types?

kghbln
> Karsten - I'm also still curious about your desire to have the tokens
not look like buttons; but maybe that's a minor thing.

It indeed appears to be a minor thing. Out of the box the token values
are wrapped into a distinct border + some background colour + the "x" at
the beginning which makes them look very much like buttons - at least to
me. However, I just tested and it is quite easy to manipulate the CSS
for this as it fits best. So I am cool here.

I was a bit surprised to read that people actually seem to prefer
tokens. So I am the problem here. ;)

Cheers Karsten

Am 25.04.2016 um 17:47 schrieb Yaron Koren:

> Hi,
>
> Thanks to everyone for the additional comments, and I look forward to
> hearing anything else people have to say.
>
> Simon, Henri - it's true that the selection process with the Select2 inputs
> is kind of annoying; it would be better if the value showed up in the input
> when you get to it with the arrow key in the dropdown, as happens with the
> ".... with autocomplete" inputs. (I hope that made sense.)
>
> Ad - I think "tokens" handles a large number of values just fine.
>
> So, I think it's clear at this point that the "text[area] with
> autocomplete" inputs, i.e. the inputs that use jQuery UI, are still
> necessary; which makes this more of a comment thread about "issues people
> have with tokens". :)
>
> To summarize the comments, it seems to me that the necessary changes that
> would have to be made, before any input types can really be removed, are,
> in rough order from most to least necessary:
>
> - Allow the tokens input to be taller when starting out, to make it clearer
> that it can expand
> - Have the tokens input un-tokenize values when they are double-clicked
> - Have both input types support the "uploadable" parameter
> - In some way, let users select a value in these input types without either
> hitting "Enter" or clicking a mouse.
>
> Karsten -  I'm also still curious about your desire to have the tokens not
> look like buttons; but maybe that's a minor thing.
>
> By the way, if there's a JavaScript autocompletion library that already
> offers all of these features, I would be happy to consider switching to
> that one; I haven't found one. Tokenized autocompletion (also referred to
> as "tag-style autocompletion", and similar) is not supported in general by
> a lot of JS libraries, despite its obvious (in my view) advantages.
> Hopefully that will change in the future.
>
> Also, I looked up the un-tokenizing thing in the Select2 forum, and indeed
> this is a popular request; see here:
>
> https://github.com/select2/select2/issues/116
>
> If you scroll down to the bottom, this issue was closed in 2014 in what I
> would consider an unsatisfactory way: they added the ability to un-tokenize
> only the last value in the set - by hitting the "backspace" key - and
> considered the issue resolved. But earlier in that thread a few people
> offer JS patches that claim to do what we've been talking about, with the
> double-clicking; hopefully one of those can be added here.
>
> -Yaron
>

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
Reply | Threaded
Open this post in threaded view
|

Re: [SF] Removing "text with autocomplete", "textarea with autocomplete" input types?

Yaron Koren-2
In reply to this post by Yaron Koren-2
Hi,

I looked into the first issue - having the "tokens" input be more than one
row tall - and decided that the best solution for it was through some
custom CSS. I added instructions for how to apply it here:

https://www.mediawiki.org/wiki/Extension:Semantic_Forms/Input_types#tokens

Based on people's previous responses, I guess this change by itself might
be enough to get some people to switch to using the "tokens" input - though
it's probably enough to enable dropping the "... with autocomplete" inputs.

-Yaron

On Mon, Apr 25, 2016 at 11:47 AM, Yaron Koren <[hidden email]> wrote:

> Hi,
>
> Thanks to everyone for the additional comments, and I look forward to
> hearing anything else people have to say.
>
> Simon, Henri - it's true that the selection process with the Select2
> inputs is kind of annoying; it would be better if the value showed up in
> the input when you get to it with the arrow key in the dropdown, as happens
> with the ".... with autocomplete" inputs. (I hope that made sense.)
>
> Ad - I think "tokens" handles a large number of values just fine.
>
> So, I think it's clear at this point that the "text[area] with
> autocomplete" inputs, i.e. the inputs that use jQuery UI, are still
> necessary; which makes this more of a comment thread about "issues people
> have with tokens". :)
>
> To summarize the comments, it seems to me that the necessary changes that
> would have to be made, before any input types can really be removed, are,
> in rough order from most to least necessary:
>
> - Allow the tokens input to be taller when starting out, to make it
> clearer that it can expand
> - Have the tokens input un-tokenize values when they are double-clicked
> - Have both input types support the "uploadable" parameter
> - In some way, let users select a value in these input types without
> either hitting "Enter" or clicking a mouse.
>
> Karsten -  I'm also still curious about your desire to have the tokens not
> look like buttons; but maybe that's a minor thing.
>
> By the way, if there's a JavaScript autocompletion library that already
> offers all of these features, I would be happy to consider switching to
> that one; I haven't found one. Tokenized autocompletion (also referred to
> as "tag-style autocompletion", and similar) is not supported in general by
> a lot of JS libraries, despite its obvious (in my view) advantages.
> Hopefully that will change in the future.
>
> Also, I looked up the un-tokenizing thing in the Select2 forum, and indeed
> this is a popular request; see here:
>
> https://github.com/select2/select2/issues/116
>
> If you scroll down to the bottom, this issue was closed in 2014 in what I
> would consider an unsatisfactory way: they added the ability to un-tokenize
> only the last value in the set - by hitting the "backspace" key - and
> considered the issue resolved. But earlier in that thread a few people
> offer JS patches that claim to do what we've been talking about, with the
> double-clicking; hopefully one of those can be added here.
>
> -Yaron
>


--
WikiWorks · MediaWiki Consulting · http://wikiworks.com
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
Reply | Threaded
Open this post in threaded view
|

Re: [SF] Removing "text with autocomplete", "textarea with autocomplete" input types?

Yaron Koren-2
I just happened to re-read this email, and realized that I wrote "probably
enough" in the last sentence, when I meant to write "probably not enough"!
Sorry for the confusion.

-Yaron

On Mon, May 2, 2016 at 5:16 PM, Yaron Koren <[hidden email]> wrote:

> Hi,
>
> I looked into the first issue - having the "tokens" input be more than one
> row tall - and decided that the best solution for it was through some
> custom CSS. I added instructions for how to apply it here:
>
> https://www.mediawiki.org/wiki/Extension:Semantic_Forms/Input_types#tokens
>
> Based on people's previous responses, I guess this change by itself might
> be enough to get some people to switch to using the "tokens" input - though
> it's probably enough to enable dropping the "... with autocomplete" inputs.
>
> -Yaron
>

--
WikiWorks · MediaWiki Consulting · http://wikiworks.com
------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
Semediawiki-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/semediawiki-user