Loomio

Improving and expanding hashtags usability.

S Shmerl Public Seen by 161

Current functionality of hashtags in Diaspora has several limitations. I'll list them first (if you can come up with more - feel free to comment):

  1. User can only follow a straight list of tags (i.e. following is defined with logical OR).

  2. User can't filter tags for not following (i.e. not to see some content which has them).

  3. Viewing options of followed tags in the UI are limited to either viewing all followed tags, or only one.

  4. Search is limited to one tag.

  5. Hashtags themselves don't allow whitespace in them which is caused by the syntax restrictions and results in awkward unreadable notations like "#areallylonghashtagyoucanbreakyoureyeson", or people trying to come up with workarounds (like using underscore or camel notation, which proliferates incompatible tags and defeats the purpose of searching by them).

To address these issues, several improvements can be made (these proposals match the problems described above).

1-2. Following by default can still be defined as a simple list (which is equal to tag1 OR tag2 OR tag3 OR ... OR tagN). Interested user can be given an advanced option to define a more complex boolean expression for following hashtags. I.e. allow using AND, OR, NOT and parentheses. This will cover both 1 and 2, allowing way more flexible method of following and filtering data.

  1. When using the UI for viewing, one should be given a way to view one, several or all (multiple select) of those hashtags. This is sufficient for the UI case. More complex view will be covered with search (4).

  2. Search should allow boolean expressions, the same way the following in the proposal (1-2).

  3. Syntax of hashtags can be expanded. For example it can allow such form in addition to simple not whitespaced tags:

#(some phrase with spaces)

In the final text it can look like a hyperlink without parentheses:

#some phrase with spaces

Parentheses are used just for definition, to delimit the beginning and the end of the tag. This will give a clean way to avoid multiple incompatible notations for complex multiword hashtags.

L

L3MNcakes Tue 25 Jun 2013 5:14PM

I believe there is a feature proposal out there that could solve many of these by allowing users to create custom streams based on some logic that they define. Been away for a while though, so not quite sure on it's status.

As for #5, I don't think allowing whitespace in hashtags is a good idea. The way I view hashtags, they should be as simple and to the point as possible. A quick way to figure out what ideas are trying to be expressed in the post, not an expression of an idea itself. That's just my opinion though, and the community may see hashtags differently. :)

S

Shmerl Wed 26 Jun 2013 6:22AM

@l3mncakes: About whitespace in hashtags. Users already often use multiword hashtags - you can't force them to stop doing it, so we just need to accept it. The point of the proposal is to create a better syntax for using them, which will result in cleaner looking hashtags which would follow one convention, reducing incompatible duplicates.

L

L3MNcakes Wed 26 Jun 2013 5:25PM

@Shmerl - I don't advocate forcing anybody to stop using multi-word hashtags if that's what they want to do, but I don't see how allowing this will do anything to reduce incompatible duplicates. If anything, I only see it perpetuating them by increasing the possibilities of variation that come out of using multi-word hashtags in the first place. The same way I can't force people to not use multi-word tags, I also can't force everybody to start using spaces in their tags. People will still use the no space or underscore or camelcase variations, so all I see this doing is further fracturing the conversation. Since one of the goals of our network is to facilitate topical conversation and interaction, I see this as being counter-intuitive to our goals, which is why I don't think it's something we should build into the system just because some people out there use hashtags that way. Of course, I'm far from the end-all decider here, so my single objection doesn't mean this won't happen if there is support for it. ;)

S

Shmerl Fri 28 Jun 2013 4:13AM

You create a better option, and help people to understand better ways of using multiword hashtags through FAQs and tutorials. In the end people would use whatever they want. But giving an option of using cleaner syntax and better readability is a good thing.

S

Shmerl Fri 28 Jun 2013 4:16AM

As I said - we are dealing with existing factor - i.e. people are already using multiword hashtags, but there is no clean syntax which would produce readable resutls. That's the issue that can be addressed. Convergence of hashtags can be also achieved through loose search. I.e. the search can allow ignoring the whitespace and underscores differences, which would allow joining the results.

A

AlexB Tue 20 Aug 2013 9:44PM

I just wanted to say I think this is a crucial feature. Just one further thing to suggest -- incorporating the possibility of specifying a post-author in these complex follow/search terms. One could thus follow or search for everything a particular person says about a particular subject.

(I mean using @-(name) in the complex search outlined by Shmerl above as a way of seeing posts /by/ that particular user which include the specified hashtags. I suppose there could also be a way of following/searching for posts which include the specified hashtags AND @-mentions of a particular user, i.e. posts about a topic and about that user.)

This would complement the "Aspects" feature. As I understand it, "Aspects" allow the poster to compartmentalise their followers (e.g. "I'm only going to send my political rants to my family"). My suggestion would effectively allow the follower to compartmentalise those they follow ("I only care about X's posts about Linux, not her holiday photos").

JS

Juan Santiago Wed 23 Jul 2014 10:30PM

Some time ago, I think to present a proposal like this,

Is a little improvement Diaspora *search engine

1) can search a combination of tags, eg + #nature #photo
2) can search users combining by tags, eg: juansantiago@joindiaspora.com + #palestine

K

Kazhnuz Tue 29 Jul 2014 1:19PM

I pretty like the idea of using a "loose search", because it would solve the problem of fragmentation of tagging convention, and if someone follow "#supertuxkart", he would see : #super-tux-kart, #super_tux_kart, #supertuxkart, #SuperTuxKart... It would make the hashtag more usable, I think. Combined to the idea of Juan Santiago and the possibility to follow hashtag combination, it would make the whole diaspora search engine and tagging system way more powerfull.

R

riveravaldez Tue 28 Oct 2014 8:44PM

Multiple-tags search is also usable (and I often find myself desiring it) to refine a search, like: #web #browsers #GPL, or whatever.
I suppose this will came at hand with the 'multiple-tags-selection' to refine a certain streaming.

C

Chris Wed 29 Oct 2014 10:48AM

I don't know about the specific terms.

What if we switch from the [space] character to a comma to separate tags?

I think what follows from this would be a tag field which is seperate from the main content of the post. If this is not implemented, it may result in a lot of clumsiness from users who #like to place #tags #in-line with their #posts instead of appending tags to the end.

Another method might be to separate tags with a double-[space].

In any case, I heartily approve of multiple tag, as well as author+tag searching.

JS

Juan Santiago Wed 29 Oct 2014 8:17PM

@chris26 @riveravaldez @kazhnuz @shmerl

I think I have distracted the subject of this thread.

Is it appropriate to create a new thread to discuss about combined search?

or someone who draws better than me in English, created here vote for that?

C

Poll Created Thu 30 Oct 2014 3:18AM

multi-word hashtags should be enabled by requiring two hashes Closed Sun 2 Nov 2014 2:08AM

Outcome
by Chris Tue 25 Apr 2017 5:16AM

Not passed. Bad/confusing syntax.

Multi-word hashtags should be enabled by requiring one hash (#) preceding a non-[space] charater and another hash following a non-[space] character.

If there is no hash symbol in the text which follows a non-space character, it should be assumed that the last character in the tag is before the nearest [space]

For example, #this is a multiple word tag#.

And #this sentence only contains one tag.

This would allow people to use single- and multiple-word tags in-line with the text of their post. multi-word hashtags are not created accidentally, no new fields have to be created specifically for hashtags.

Results

Results Option % of points Voters
Agree 10.0% 2 KAK C
Abstain 10.0% 2 JS DU
Disagree 80.0% 16 FS JH JR G RF RS- IGM S SVB N A X D DU A DM
Block 0.0% 0  
Undecided 0% 132 JL BK ST MS TS AA S CB HF BO DM GC JH F M EG G AX PC PP

20 of 152 people have voted (13%)

C

Chris
Agree
Thu 30 Oct 2014 3:28AM

It seems to me like this option would be the most natural for the user.

S

Shmerl
Disagree
Thu 30 Oct 2014 3:34AM

It makes parsing more complex. See more details in the main comments.

RF

Rasmus Fuhse
Disagree
Thu 30 Oct 2014 8:26AM

Don't like the syntax. See comment

JH

Jonne Haß
Disagree
Thu 30 Oct 2014 10:04AM

What has been said. Also you just need to accidentally swap space and # when defining multiple tags on the same line to make an accidental one. Besides I don't actually see any need to change syntax for mult-word tags.

FS

Florian Staudacher
Disagree
Thu 30 Oct 2014 11:11AM

I don't think mulit-word hashtags are the solution. It just makes stuff more complicated all around.

G

goob
Disagree
Thu 30 Oct 2014 5:46PM

I think this would cause problems as suggested above.

DU

[deactivated account]
Disagree
Thu 30 Oct 2014 8:48PM

Useless. Just the result of a misunderstanding how tags work.

DU

[deactivated account]
Agree
Thu 30 Oct 2014 10:30PM

#"multi-word hashtags" can automatically generate the other variants that proliferate (because natural syntax was not implemented for tags in the first place!). No other variant can generate the term #"multi-word hashtags".

IGM

Ivan Gabriel Morén
Disagree
Thu 30 Oct 2014 10:51PM

Syntax in proposal is too different from how hashtags are viewed. IMO parantheses that are stripped out when rendering the post would suit the purpose better.

DU

[deactivated account]
Abstain
Thu 30 Oct 2014 10:57PM

+1 Chris' modified proposal. #"multi-word hashtags" can generate the other variants that proliferate (because natural syntax wasn't implemented for tags in the first place!). No other variant can generate the term #"multi-word hashtags".

A

AlexB
Disagree
Fri 31 Oct 2014 8:27AM

Using same character to close and open creates ambiguity for parser.

KAK

Karthikeyan A K
Agree
Sat 1 Nov 2014 2:13AM

Looks bit confusing, but its okay

A

Asher
Disagree
Sat 1 Nov 2014 7:06AM

I don't seem any need for this and I think it will just confuse newcomers more.

A

Asher
Disagree
Sat 1 Nov 2014 7:06AM

I don't see any need for this and I think it will just confuse newcomers more.

RS-

Robin Stent - Outreach
Disagree
Sat 1 Nov 2014 9:01AM

This would be open to confusion from a user point of view. On twitter people use capitalisation to denote words which seems to work pretty well. Tags in general, not just on social media are meant to be short identifiers to search by not essays

D

dremodaris
Disagree
Sat 1 Nov 2014 11:10AM

Confusing and unnecessary.

X

Xophael
Disagree
Sat 1 Nov 2014 2:04PM

on syntax, doesn't look like a standard practice.

DM

D. Moonfire
Disagree
Sat 1 Nov 2014 2:53PM

With that format, it would hard to parse those who intermix their tags or accidentally transpose two characters.

And #cheese #wagon trip# bob #gary ops# missed# #that.

S

Shmerl Thu 30 Oct 2014 3:25AM

@juansantiago : This proposal covers advanced search, so you can add your implementation details if you want.

I think they are related, since following tags and actual search all perform queries based on similar logic. So implementation will likely have a lot of shared parts.

S

Shmerl Thu 30 Oct 2014 3:33AM

@chris26 : I think such syntax is prone to more problems than more clearly defined #(...) I.e. it has higher ambiguity during analysis. In case of using regular tags you'll still have to parse the whole text (either until the end, or until the next # used in the next tag) before figuring out whether the previous one was a regular tag or you still didn't reach the end of the multiword tag. It's rather demanding and introduces complexity.

On the other hand, if you see #( you know right away that you are starting a multiword tag. It means less ambiguity and simpler parser.

C

Chris Thu 30 Oct 2014 3:41AM

@shmerl : Your vote makes sense to me. This is also a concern of mine. But I wonder. Are we talking about the parser being outright prone to failure? Or are we talking about the amount of work required for a CPU?

If the latter, how much difference are we really talking about?

S

Shmerl Thu 30 Oct 2014 3:51AM

@chris26 : Any difference can reduce performance. In this case it also affects readability at editing time. When you edit the post, you can easily see beginning ( and ending ). And when you use exactly the same symbol for beginning and end of the tag - you'll have hard time visually catching them. I would have liked your proposal more if at least you used different symbols for beginning and end (that won't solve the issue of parser complexity, but at least would improve readability at editing time).

S

Shmerl Thu 30 Oct 2014 3:53AM

Alternatively you can simply use another symbol altogether to reduce ambiguity (i.e. less common one than round brackets which are often used in text).

Example:

{multi word tag}

Then there won't be a need to put # in the beginning at all and it would be readable and easy to parse.

C

Chris Thu 30 Oct 2014 4:21AM

curly-brackets sounds like a plan to me. Leave the functionality of #, and add {} tags.

RF

Rasmus Fuhse Thu 30 Oct 2014 8:25AM

I want to second Shmerls argument here. #bla bla# might cause unwanted ambiguities and makes the code bad to test. I'd also prefer something like #(..) #"..." #[...] or #{...}.

DM

D. Moonfire Thu 30 Oct 2014 5:13PM

My suggestion is to use something that fits more with the Markdown syntax that Diaspora already uses. Since we have name, why not just use [Tag Link] by itself. It is fairly easily to parse. Though, if you want the hash, I'd be more inclined to say [#Tag Phrase].

JH

Jonne Haß Thu 30 Oct 2014 5:42PM

Can someone explain why we even need tags with whitespace?

DU

[deactivated account] Thu 30 Oct 2014 6:22PM

"5. Hashtags themselves don’t allow whitespace in them which is caused by the syntax restrictions and results in awkward unreadable notations like “#areallylonghashtagyoucanbreakyoureyeson”, or people trying to come up with workarounds (like using underscore or camel notation, which proliferates incompatible tags and defeats the purpose of searching by them)."

I think that the proliferation of alternate syntaxes is a great problem.

S

Shmerl Thu 30 Oct 2014 6:39PM

I think that the proliferation of alternate syntaxes is a great problem.

That's the point - making one standard in diaspora* will reduce usage of other makeshift methods like described. And will increase readability.

S

Shmerl Thu 30 Oct 2014 6:40PM

@jonnehass :

Can someone explain why we even need tags with whitespace?

It's explained quite clearly in problem #5 in the proposal. So let me repeat it:

Hashtags themselves don’t allow whitespace in them which is caused by the syntax restrictions and results in awkward unreadable notations like “#areallylonghashtagyoucanbreakyoureyeson”, or people trying to come up with workarounds (like using underscore or camel notation, which proliferates incompatible tags and defeats the purpose of searching by them).

JH

Jonne Haß Thu 30 Oct 2014 6:45PM

I think caml casing is common enough and works fine, I'd even consider removing support for _ in tags. We already downcase for comparison, so #fooBar, #FooBar and #foobar are all the same tag.

DU

[deactivated account] Thu 30 Oct 2014 6:46PM

Can someone explain why we even need tags with whitespace?

No idea. I gues it's because of a misunderstanding about the usage of hashtags, but it's only suppositions.

I think this all needs a serious police investigation. please call the experts ! :D

C

Chris Thu 30 Oct 2014 6:51PM

What if dashes were automatically deleted? That way, for example, #GNU-Linux and #GNULinux would all end up at #gnulinux. Also, if the curly-bracket thing is implemented, #{GNU Linux} would also go to the same place.

Right off, I can tell this would be inconvenient/insensitive when talking about someone with a hyphenated name. I'm just spit-balling.

S

Shmerl Thu 30 Oct 2014 6:52PM

All of this is not a question why we need multiword hashtags. They are already used and in all kind of incompatible ways. This proposal is about making a clean syntax rather than leaving this chaotic.

#FooBar is bad (not readable for long tags). #foo_bar or #foo-bar are not compatible with #FooBar and etc. But all of them are used to convey the same idea. All of those problems are described in #5. Whitespace in tags would provide one standard way and would make them actually human readable (which is important!).

G

goob Thu 30 Oct 2014 6:53PM

I’d even consider removing support for _ in tags.

I think it would be good to allow users to create tags containing underscores and hyphens, but to 'strip' these characters from the linked tag, so a search for #foobar also returns results from #foo_bar and #foo-bar.

I see no benefit in coding for tags with spaces in - that seems to me something which is just going to create all sorts of situations in which users create tags when they don't mean to, and so on.

S

Shmerl Thu 30 Oct 2014 6:54PM

I'd prefer not to strip anything from tags and use them as the user intended. Otherwise it will only increase the confusion.

RF

Rasmus Fuhse Thu 30 Oct 2014 6:59PM

I thought this topic was somehow related to the approach to realize groups through a hashtag. That would seem like a nice idea to me although I would prefer to realize groups with something else.

But concerning readability: we might get a conflict between readability and writability. Let's imagine the hashtags #merrychristmas and #{merry christmas}. Which one would you use in your postings AND which one are you expecting that other users are using in their postings? In fact I expect curly brackets to be so hard to type that only the super-hardcore-nerds would ever use them.

DU

[deactivated account] Thu 30 Oct 2014 7:01PM

What if dashes were automatically deleted? That way, for example, #GNU-Linux and #GNULinux would all end up at #gnulinux. Also, if the curly-bracket thing is implemented, #{GNU Linux} would also go to the same place.

To me, implement another syntax is just visual pollution. For long tags, you just have camel case. I have never understood the nedd for doing sentences with hashtags...

They are juste used to sort posts in subject, not write these posts.

C

Chris Thu 30 Oct 2014 7:09PM

super-hardcore-nerds

No, something only super-hardcore-nerds would use would be merry christmas.

And it's not like we're dealing with tildas ( ~ ) or pipes ( | ) or anything. I think curly-brackets are fairly understandable. Maybe straight brackets ( [ ] ) would would be preferred, just so you don't have to hit the Shift key quite so much.

I don't think it's any more difficult than embedding an image with Markdown.

S

Shmerl Thu 30 Oct 2014 7:44PM

To me, implement another syntax is just visual pollution. For long tags, you just have camel case.

Which is unreadable - I simply never waste my time on breaking eyes on such hahstags.

DU

[deactivated account] Thu 30 Oct 2014 7:52PM

Our syntax, with spaces, is not just another syntax, it's our natural syntax. The maddening proliferation of four different syntaxes (CamelCase, hyphens, no space, hashtags on each word) only results from our initial inability to emulate it. Obviously the natural syntax will catch on everywhere if only we give it a chance and D* is a good place to start.

#"natural syntax"

S

Shmerl Thu 30 Oct 2014 7:53PM

But concerning readability: we might get a conflict between readability and writability.

Let's clarify. The result can be displayed in the post without brackets at all. Brackets are needed only for editing the post.

DU

[deactivated account] Thu 30 Oct 2014 7:59PM

Which is unreadable - I simply never waste my time on breaking eyes on such hahstags.

Tags are not intended to write sentences, yet. I really don't see the need for writing super-long hashes. #ConsiderImWritingMyPostsEntirelyWithTags #IsItUsefull ?

Really, tags are just a way to mark a post as concerning a subject. Nothing else....

DU

[deactivated account] Thu 30 Oct 2014 8:20PM

Sentences are off-topic. We're dealing with terms.

"Terms are words and compound words that in specific contexts are given specific meanings—these may deviate from the meanings the same words have in other contexts and in everyday language."

S

Shmerl Thu 30 Oct 2014 8:31PM

Really, tags are just a way to mark a post as concerning a subject. Nothing else….

Yet they are often used inside posts. So we can either ignore current lack of readability, or we can improve it. I'm for the second option.

DU

[deactivated account] Thu 30 Oct 2014 8:44PM

Yet they are often used inside posts.

Which is pretty stupid to me. But that's just my feeling...

So we can either ignore current lack of readability, or we can improve it. I’m for the second option.

I'm for the first. I'm really sick tired of the proliferation of the hashtags which reduces the readability and are really useless in other usage than categorize a post.

JS

Juan Santiago Thu 30 Oct 2014 8:47PM

New thread with the proposal to improve search https://www.loomio.org/d/fKts1wR2/improvement-diaspora-search-engine

JH

Jonne Haß Thu 30 Oct 2014 9:21PM

I'd say trying to stop ambiguity by introducing yet another syntax is a fallacy, especially if it requires distinct syntax and thus knowledge. All this leads to is that we would not only have #foobar, #foo_bar and #foo-bar (I actually wouldn't mind disallowing _ and - in tags altogether), but also #"foo bar". Given enough users all versions will always exist.

S

Shmerl Thu 30 Oct 2014 9:33PM

I’d say trying to stop ambiguity by introducing yet another syntax is a fallacy

No. Having no standard way of making multiword hashtags and expecting all users to follow one way is a fallacy. Having a standard at least gives users an option to follow it, and others to point to it if they see it not being followed. Having no standard means what it means - legitimate chaos. No one will force users to follow it anyway, we are talking about giving a standard option.

You can write hashtags backwards for all I care. But if there is no standard option, you can't even start talking to anyone about following one notation.

IGM

Ivan Gabriel Morén Thu 30 Oct 2014 10:01PM

So why not support all the different ways that are currently possible?

I think it would be good to allow users to create tags containing underscores and hyphens, but to ‘strip’ these characters from the linked tag, so a search for #foobar also returns results from #foo_bar and #foo-bar. (@goob)

Fuzzy tags would make diaspora's way of treating hashtags modern and easy to use.

Oh, and I don't think #hashtags should contain whitespace because if they do, the other words look like links or just like they're lost and lonely. I mean, look at this one.

#going out with the dog

DU

[deactivated account] Thu 30 Oct 2014 10:20PM

"#Going out with the dog", with the traditional distinctive colour, is as readable as any other hyperlink.

Using a known syntax, natural syntax, does not require prior knowledge.

The absurd proliferation of syntax variants is a result of not having a natural syntax in the first place and I applaud Schmerl's proposal.

Re : stripping tags of hyphens, underscore, etc : You can easily retrieve variants from the #"natural syntax" tag (#NaturalSyntax, #natural-syntax, etc.) but it is close to impossible to reliably automate the generation of other variants from #naturalsyntax. It's a dead end.

In contrast, the implementation of #"natural syntax" on D* could involve the semi-automatic generation of common variants : #NaturalSyntax and #natural-syntax.

DU

[deactivated account] Thu 30 Oct 2014 10:32PM

“#Going out with the dog”, with the traditional distinctive colour, is as readable as any other hyperlink.

There's at least one reason why hyperlinks do not contain white spaces. White space are traditionnaly the separator bitween two distinctive elements. A link with a white space in the middle isn't one link. It is one link and something else.

This will be a mess to process.

And I still don't understand the need for making sentences with hashtags...

S

Shmerl Thu 30 Oct 2014 10:44PM

@Perig Gouanvic : I think you agreed in the last vote not to the original proposal, but to the specific implementation proposed by Chris.

S

Shmerl Thu 30 Oct 2014 10:46PM

There’s at least one reason why hyperlinks do not contain white spaces.

What are you talking about? There are tons of hyperlinks with whitespace. Even on Diaspora stream page itself. For example "Post to diaspora*" (bookmarklet).

IGM

Ivan Gabriel Morén Thu 30 Oct 2014 10:47PM

You can easily retrieve variants from the #“natural syntax” tag (#NaturalSyntax, #natural-syntax, etc.) but it is close to impossible to reliably automate the generation of other variants from #naturalsyntax. It’s a dead end.

I think you misunderstood. Of course it's hard to try to query all variants of a hashtag, a search for #cat would need to check for #c-at, #ca-t, #cAt, #cA-t_ and so on. Therefore stripping functionality should occur at the same time as the lowercase modification, when the post is written. Correct me if I'm wrong.

S

Shmerl Thu 30 Oct 2014 11:01PM

After this one ends, I can create a vote on proposal matching the original idea of #(...) or similar method.

DU

[deactivated account] Fri 31 Oct 2014 7:32AM

What are you talking about? There are tons of hyperlinks with whitespace. Even on Diaspora stream page itself. For example “Post to diaspora*” (bookmarklet).

I speak about hyperlinks. Not overlying text.

S

Shmerl Fri 31 Oct 2014 7:45AM

Hyperlinks perfectly allow whitespace.

Example:

<a href="something">that's a hyperlink with whitespace!</a>.

How is it any different than:

#(that's a tag with whitespace which will look like hyperlink in the text)
DU

[deactivated account] Fri 31 Oct 2014 7:47AM

https://www.loomio.org/d/R3zBvnfc/improving-and-expanding-hashtags-usability

No whitespaces...

My point is it is useless and it is deploying useless efforts to solve an inexistant problem. For the third time : I don't see the need for making sentences with hashes.

S

Shmerl Fri 31 Oct 2014 7:51AM

See my example above. Hyperlinks can have whitespace, period. It was always used in hypertext. What you posted is an URL, not a hyperlink. I see no point in redefining what a hyperlink is.

inexistant problem

The problem was explained clearly (proliferation of incompatible tags and no standard with natural way of using simple notation). It's not non existent, you just don't consider it a problem while others do.

A

AlexB Fri 31 Oct 2014 8:08AM

I like the point that the curly brackets would only be at the writing stage. If they came in at the reading stage too (i.e. appeared in posts) that would just be another syntax.

S

Shmerl Fri 31 Oct 2014 8:12AM

@alexb : The original proposal is relevant to the writing stage. I.e. result will look like #multiword tag. Curly brackets can also translate into the same result when page is displayed.

A

AlexB Fri 31 Oct 2014 8:23AM

Ah -- I thought you had moved to supporting curly brackets. I think they're better than rounded brackets because we do use rounded brackets so much more in everyday sentences. It seems to me easier for the post-writer to quickly scan the post they've written before pressing "post" and differentiate asides (round brackets) from multiword hashtags (curly brackets).

Apart from that difference, I meant to approve what you had written rather than suggest a revision. As your example in your last post shows (to me, anyway), the reader knows from the hyperlink highlighting that the set of words are all one link, and knows from the hash that the link is a tag. It's a simple and natural way of displaying it.

S

Shmerl Fri 31 Oct 2014 8:29AM

I'm OK with using curly brackets preceding them with the hash:

#{some tag} which will look like #some tag in the actual displayed post.

I agree that it's cleaner than using round brackets which are more common for regular punctuation.

DU

[deactivated account] Fri 31 Oct 2014 8:46AM

See my example above. Hyperlinks can have whitespace, period.

Ok ! If you put a period, I just have to deal with it.
Best argument ever !

G

goob Fri 31 Oct 2014 11:59AM

@shmerl

I’d prefer not to strip anything from tags and use them as the user intended. Otherwise it will only increase the confusion.

The tag can still be displayed with any underscores/hyphens inserted by the user, but it would be parsed as if no hyphens/underscores were present. This would (I think) improve tag searches, while still allowing users to present tags as they like.

After this one ends, I can create a vote on proposal matching the original idea of #(…) or similar method.

Wouldn't it be a good idea first to have a vote on allowing tags containing spaces (yes/no), before having many different votes on different syntaxes for tags containing spaces? There would only be any point in making proposals for different syntaxes if there is a vote of yes for having tags containing spaces.

G

goob Fri 31 Oct 2014 12:02PM

One other consideration is how tags created in Diaspora will function in other services to which posts containing tags are pushed. For instance, Twitter.

Now I don't think we should be constrained in what we do by the limits or expectations of other social services, but where Diaspora offers cross-connectivity, we should make sure any changes built in will allow that connectivity to continue functioning properly.

S

Shmerl Fri 31 Oct 2014 3:33PM

@goob : There can be several ways to deal with pushing to other more limited services. Either you skip multiword tags, or you convert them to some other notation as a fallback (snake, camel, whatever). As you said, diaspora* shouldn't be constrained just because other such services have less functionality.

S

Shmerl Fri 31 Oct 2014 3:36PM

Wouldn’t it be a good idea first to have a vote on allowing tags containing spaces (yes/no) before having many different votes on different syntaxes for tags containing spaces?

Spaces are an example of syntax for multiword tags and an important part of the proposal to improve usability. If you want I can make a vote on spaces first.

S

Shmerl Fri 31 Oct 2014 3:37PM

@augier : Sorry, but if you want to use different definition, it will only confuse the discussion. Please stick to the accepted terms so others would understand what you really mean.

JR

Jason Robinson Sat 1 Nov 2014 8:24AM

Please extend the proposal for a longer time, core features like this should not be voted in 3 day proposals. At least two weeks would give more people time to give an opinion. Personally I'm strongly against this, but just saying that this is not the way votes should happen, with only 3 day possibility to vote, imho.

S

Shmerl Sat 1 Nov 2014 11:49PM

Please extend the proposal for a longer time, core features like this should not be voted in 3 day proposals.

The vote is not about the core feature proposal, it's about a particular syntax idea from @chris26 . Please read the details of the vote.

I'll make next vote about the original proposal longer.

S

Shmerl Sat 1 Nov 2014 11:51PM

On twitter people use capitalisation to denote words which seems to work pretty well.

I don't think Diaspora should worry about what Twitter does exactly. We should evaluate what is useful for Diaspora itself. And different incompatible ways of using multiword tags are a problem, no matter what Twitter does.

RS-

Robin Stent - Outreach Sun 2 Nov 2014 12:57AM

It's important to note that the hashtag came about organically on Twitter as a way users came up with themselves to denote the subject of their post. It was only after this became an obvious trend that Twitter made it part of their site's function. So coming up with a new syntax for hashtags on Diaspora would conflict with natural usage, so seems rather foolish.

So @shmerl when I reference Twitter I'm talking about how people naturally use the medium, not how Twitter has decided to make something function.

S

Shmerl Sun 2 Nov 2014 1:18AM

So coming up with a new syntax for hashtags on Diaspora would conflict with natural usage, so seems rather foolish.

You miss the point. Users already use multiword tags, whether you consider it foolish or not. This proposal is about giving a standard option to do it, instead of what is happening now. There is no "natural" uniform usage now. There are many natural incompatible usages.

S

Poll Created Sun 2 Nov 2014 2:38AM

Create a standard syntax for multiword tags with whitespace Closed Mon 17 Nov 2014 2:05AM

Outcome
by Shmerl Tue 25 Apr 2017 5:16AM

Summary: majority disagreed.

Not everyone explained the reasons. Those who specified reasons mostly said it’s either confusing or doesn’t work with other networks. Some said they don’t see any readability problem so there is no need to do anything about it. Some brought an example of Red Matrix which actually implements that feature.

At present tags don’t allow whitespace in them which is caused by the syntax restrictions and results in awkward unreadable notations for multiword tags like “#areallylonghashtagyoucanbreakyoureyeson”, or people trying to come up with workarounds like using snake or camel notation, which proliferates incompatible tags and defeats the purpose of searching by them.

One standard notation which allows whitespace will give a readable (that's important!) option for users to use as a uniform way of writing such tags. This proposal is generic. Particular syntax ideas for writing such tags can be proposed after voting on the general idea.

Results

Results Option % of points Voters
Agree 29.2% 7 S B SM C DU DM DU
Abstain 0.0% 0  
Disagree 66.7% 16 JH JR G BB T RS- IGM SVB N V A DB DU A J Y
Block 4.2% 1 S
Undecided 0% 129 JL BK ST FS MS TS AA S CB HF BO DM GC JH F M EG G AX PC

24 of 153 people have voted (15%)

S

Shmerl
Agree
Sun 2 Nov 2014 2:40AM

Such feature will allow reducing the usage of incompatible methods for multiword tags and will increase their readability.

JR

Jason Robinson
Block
Sun 2 Nov 2014 3:26AM

From disagree to strong block due to author acting hostile, with no interest in opposing opinions. Trying to ban multi-word tags? Really. Please concentrate on subject and not suppressing opinions by word play.
Hostility doesn't help your proposal.

SM

Seth Martin
Agree
Sun 2 Nov 2014 5:20AM

Restrictions are bad and there is a legitimate need for multi-word-hashtags with whitespace. I don't particularly think that there should be a restriction to one standard notation which allows whitespace. #"multi word" being banned would be confusing

JH

Jonne Haß
Disagree
Sun 2 Nov 2014 11:02AM

Hashtags are tags, not categories or descriptions. See 1) and 11) at http://en.wiktionary.org/wiki/tag#Noun

SVB

Steffen van Bergerem
Disagree
Sun 2 Nov 2014 11:38AM

Allowing whitespaces in tags will confuse users since it's really uncommon. If you need multiword tags you can use camel case. I don't remember anyone using snake notation but we could think about eliminating '_' when searching for tags.

S

StefOfficiel
Block
Sun 2 Nov 2014 3:25PM

The hashtag is used in the same way everywhere, a hashtag is used in "camel" mode if people write "#areallylonghashtagyoucanbreakyoureyeson" is that they do not understand how a hashtag works, it can be more confusing with a hyperlink ...

DU

[deactivated account]
Disagree
Sun 2 Nov 2014 8:02PM

Same reason. Hashes with whitespaces are useless.

JR

Jason Robinson
Disagree
Mon 3 Nov 2014 7:47AM

Changing to disagree to not confuse with block.

B

Basxto
Agree
Mon 3 Nov 2014 8:49PM

Hastags should be kept short, but since it’s the only way for finding old posts, we need multiword tags for more obvious tags.
Multiword should be better for the reading flow, when using embedded tags.

A

Asher
Disagree
Thu 6 Nov 2014 4:38AM

#CamelCase or #underscore_hashtags can already be used, I don't see the need for a new syntax. Especially considering we'll be pulling from and pushing to other networks, keep it simple.

IGM

Ivan Gabriel Morén
Disagree
Thu 6 Nov 2014 12:26PM

Limitations aren't at all evil, they provide frames for creativity and simplicity. Or should we support using images/soundstreams etc as tags too? ;)

BB

Brent Bartlett
Disagree
Sat 8 Nov 2014 3:48AM

I like camel case. Other users might use hyphens or underscores or just jam the words all together lowercase. (Not a good idea, IMO, but whatever) If you have smart search algorithms such as ignore case, hyphens, and underscores, it's not a problem

A

Airon90
Disagree
Sat 8 Nov 2014 1:29PM

Tags are used everywhere in the same way.

C

Chris
Agree
Sat 8 Nov 2014 5:16PM

tags with whitespace are used on other services, and would make things easier for users coming from new platforms. This stuff isn't going away. Example: https://www.tumblr.com/tagged/mark-gatiss

DM

D. Moonfire
Agree
Sat 8 Nov 2014 6:02PM

While camel, Pascal, and underscores all work for technical people, it doesn't always for the non-technical. Also, many systems allow multi-word tagging (Tumblr, WordPress) and we should support interop with those.

DU

[deactivated account]
Agree
Sat 8 Nov 2014 7:20PM

Tags with whitespaces are not uncommon. D* relies a lot on tags and should not be behind in the evolution of the semantic web. From this natural syntax, one can derive all other variants atuomatically (not with #CamelCase and #nospace)

Y

y.semin
Disagree
Mon 10 Nov 2014 8:22PM

I'm an humble Diaspora* user, and with no developper-sight, i just think spaceless hashtags are sufficiently widely used to be handleable, and common enough.

S

Shmerl Sun 2 Nov 2014 2:53AM

Those who disagree, please state your reasons in order to come up with better alternatives.

JR

Jason Robinson Sun 2 Nov 2014 2:54AM

Better alternative = no multi-word tags

S

Shmerl Sun 2 Nov 2014 2:55AM

Better alternative = no multi-word tags

That's impossible, you can't force it on users. They are already actively used and will be used - we'll have to live with that. This discussion is about improving usability, and not about forbidding or not multiword tags.

Simple example - #OccupyWallStreet - that's a multiword tag which expresses some single entity. You can't do the same thing with splitting it into three tags. There are many valid reasons why multiword tags can be used.

JR

Jason Robinson Sun 2 Nov 2014 2:59AM

This discussion is about improving usability, and not about forbidding or not multiword tags.

So why a proposal then if you don't take disagreement as an opinion?

S

Shmerl Sun 2 Nov 2014 3:02AM

So why a proposal then if you don’t take disagreement as an opinion?

Let me clarify. This is not a proposal to "allow / not allow" multiword tags. Such proposal is senseless. Multiword tags are already used and will be used. Forbidding them makes even less sense. How are possibly going to forbid them and what for?

This proposal is about improving usability of such tags (with providing a standard syntax of defining them).

So please state your opinion on the proposal, not on the idea of "allow or not multiword tags".

JR

Jason Robinson Sun 2 Nov 2014 3:06AM

So, this proposal is about improving usability of such tags (with providing a standard syntax of defining them).

The proposal clearly says "with whitespace". That is not something that can be done at the moment. So you are proposing multi-word tags that do not exist.

And my opinion is no. Confusing for non-geeks. Not used anywhere else. Try to please accept other peoples opinions.

S

Shmerl Sun 2 Nov 2014 3:09AM

The proposal clearly says “with whitespace”.

Yes, that's exactly the proposal on improving usability of multiword tags.

So you are proposing multi-word tags that do not exist.

Yes, that's a proposal to expand current tags syntax. Currently used multiword tags are used without whitespace which has several problems clearly described in the proposal itself.

Try to please accept other peoples opinions.

Before you said you want to forbid multiword tags altogether. That's not the same as no to whitespace. I just want to be clear that you mean the same thing.

JR

Jason Robinson Sun 2 Nov 2014 3:11AM

Before you said you want to forbid multiword tags altogether.

Such a comedian, very funny.

S

Shmerl Sun 2 Nov 2014 3:12AM

Please stay on topic and stop trolling.

S

Shmerl Sun 2 Nov 2014 3:16AM

Since Jason got confused, multiword tags means tags with many words. Syntax can be different. If anyone missed that - they are already used. Not just in Diaspora, but in Twitter and any other place which uses tags. Examples were given above.

The reason to use them is quite straightforward - sometimes you need to use phrase as a tag, and one word isn't sufficient.

S

Shmerl Sun 2 Nov 2014 3:28AM

From disagree to strong block due to author acting hostile

Who was being hostile here? You started completely off-topic and unprofessional ad hominem attacks in the discussion when you said:

Such a comedian, very funny.

and when you were asked to stop trolling you call that hostile? Be responsible please. Derailing the discussion with personal attacks is what not helping any productive results.

G

goob Sun 2 Nov 2014 11:50AM

Those who disagree, please state your reasons in order to come up with better alternatives.

Because it's a bad idea.

The proposal is based on the complaint that there are currently too many ways to enter a multi-word tag, but proposes yet another way to do it.

Better to change the parsing of tags so that, just as results containing both #mytag and #MyTag currently appear in a search for either of them, results for #my-tag and #my_tag would also appear (along with any variants of these) in a search for any of those variants.

S

Shmerl Sun 2 Nov 2014 6:17PM

The proposal is based on the complaint that there are currently too many ways to enter a multi-word tag, but proposes yet another way to do it.

@goob : That's just part of the issue. Another part of the issue is poor readability of tags without whitespace, which for some reason most here simply dismiss as irrelevant. However it makes them simply noise which distracts from reading the post, ranging from small annoyance to making the whole thing highly unreadable.

For this reason for example I always avoid using tags in the middle of the post, and just make a list of them in the end. But a lot of people mix tags with the body of the post in my experience.

S

Shmerl Sun 2 Nov 2014 6:20PM

The hashtag is used in the same way everywhere, a hashtag is used in "camel" mode

I saw plenty of hashtags used with dashes or snake notation. While Goob's idea to drop them during search will help partially, readability of such tags displayed in the post will remain very poor.

SM

Seth Martin Sun 2 Nov 2014 8:09PM

Hashtags with whitespace may be useless to you but it's not to others. There's no sense in blocking something that really does have legitimate use just because you don't want it. You're not being asked to write the code, just if there's a legitimate reason it should not happen. So far, there are no legitimate concerns.

DU

[deactivated account] Sun 2 Nov 2014 8:11PM

On a more technical mean : it will just be a pain in the ass to process. Algorithms to extract classic hashes extists. No one to extract hashes w/ whitespaces. So we'll have to code it. No way...

. Another part of the issue is poor readability of tags without whitespace

See Jonne's opinion : hashtags does not exist to be readable. They exist to agrgregate posts with subjects.

There’s no sense in blocking something that really does have legitimate use just because you don’t want it.

Not just that. I really don't care who want's it or not. I just strongly believe this will be harmful

S

Shmerl Sun 2 Nov 2014 8:19PM

Indeed, they are clearly not useless for everyone. So far concerns which were voiced were:

  1. it's confusing.
  2. tags aren't categories.
  3. the proposal can't reduce proliferation of incompatible tags.

About #1 - I'm not sure it's any more confusing than using hyperlinks with whitespace which are used everywhere. People don't look confused about it.

#2 - I'm not sure really how it affects the usage if they are categories or not. Tags are used for search and anchoring certain posts together. And they are actively used for that purpose in phrases forms already (for example - "free software", "open source" etc.). So however we defined their theoretical idea, right now we are talking about practical usage which is already prevalent.

#3: Removing proliferation completely is impossible - users can always come up with incompatible ways - you can't hold user's hands about it. But what you can do is providing an easy to read standard option.

S

Shmerl Sun 2 Nov 2014 8:23PM

Algorithms to extract classic hashes extists. No one to extract hashes w/ whitespaces

What, you say that parser for #{...} is much more complex than parser for #xyz? It doesn't look to be more complex or resource hungry. The other proposal (from Chris) was indeed introducing more complexity because of that syntax specifics. But whitespace alone - doesn't.

S

Shmerl Sun 2 Nov 2014 8:25PM

hashtags does not exist to be readable.

That was answered already. What matters is how they are used in practice, not how we define them in theory. And practice contradicts that. I.e. unreadable tags are used all around in the middle of posts which implies that you have to read them.

So ignoring that and saying - "hey, they don't follow the definition, so who cares" doesn't really help anything.

S

Shmerl Sun 2 Nov 2014 8:28PM

Not just that. I really don’t care who want’s it or not. I just strongly believe this will be harmful

Can you elaborate please how it can be harmful?

RF

Rasmus Fuhse Sun 2 Nov 2014 8:47PM

I guess, we soon will need some regularities on when and who and how can someone block a voting, how long the voting-duration should be and that code-details shouldn't be part of the decision. I think, "we cannot reuse other's people's code" (see Augier's "So we’ll have to code it. No way…") is a bad argument to reject a proposal. See, we are working on Diaspora and want to change the world; it is obvious that we can't achieve that just by using code of other people.

Nevertheless it is my own opinion that this feature is not really necessary.

DU

[deactivated account] Sun 2 Nov 2014 9:03PM

What, you say that parser for #{…} is much more complex than parser for #xyz?

I say that we do not do this job by ourselves currently. It is done by an external gem. So, yes, it is much more complex if we have to do this by ourselves...

And practice contradicts that. I.e. unreadable tags are used all around in the middle of posts which implies that you have to read them.

Seriously, how many posts do you read with very long tags ? In what does it block the message comprehension ? What I say is : hashtags should be next to the text body. Not in it, and obviously not it....

Can you elaborate please how it can be harmful?

It adds work, another confusing syntax, another way to write multi-word tags, meaning another possibility to not find all the posts related to this tag, another incompatibilty with other tools (FB, twitter, red matrix, etc...) other algorithmics problems to solve (how to display it, how to process it, how to add it in databases), etc, etc... And unfortunatly, it does not bring us devs...

S

Shmerl Sun 2 Nov 2014 9:26PM

Seriously, how many posts do you read with very long tags ? In what does it block the message comprehension

It happens not infrequently. It blocks it in a very simple way - more than often I just stop reading that post and move to the next one.

It adds work, another confusing syntax, another way to write multi-word tags, meaning another possibility to not find all the posts related to this tag, another incompatibilty with other tools

I think all of those concerns were already addressed above. Syntax isn't confusing (it's already widely used for hyperlinks) and anyway it's optional and no one is forced to use it. Search can be adjusted anyway to unify things, similar to what Goob proposed and export to other tools can be addressed on individual basis following their limitations (for example spaces can be stripped and so on). Another way to write which is standard is something that users can be directed to if they aren't aware. No standard way means you can't even suggest it properly.

SM

Seth Martin Sun 2 Nov 2014 9:35PM

another incompatibilty with other tools (FB, twitter, red matrix, etc…)

#"multi word hashtag" and #multi_word_hashtag can both be used with RedMatrix.

JR

Jason Robinson Mon 3 Nov 2014 7:46AM

@rasmusfuhse

some regularities on when and who and how can someone block a voting,

A block is only a No vote, we voted on that early on when we started using Loomio. It doesn't block anything, we just calculate no+block votes against yes.

A

Asher Thu 6 Nov 2014 4:46AM

#OccupyWallStreet works fine without spaces.
I only see disadvantages for using something like #(Occupy Wall Street)
1. It's not easier to use
2. It's not intuitive
3. It breaks compatibility with sites that use normal hashtags
What's the upshot?
That said, I do think better searching/following/filtering options would help!

S

Shmerl Thu 6 Nov 2014 4:01PM

Or should we support using images/soundstreams etc as tags too? ;)

Actually yes. There was a proposal already to support audio and video tags. Simplicity which reduces usability is not a good thing at all.

RS-

Robin Stent - Outreach Sat 8 Nov 2014 5:13PM

You want us to vote down your proposal all over again? Ok then....
I think specifying a syntax for tags is unnecessary and not a good use of people's time.

BB

Brent Bartlett Sat 8 Nov 2014 8:22PM

I guess I just don’t understand why whitespace is such a big deal. If you’re worried about appealing to “non-technical” people, anything you come up with is going to be just as “technical” as using camelCase or hyphens or whatever. As I stated earlier, this is a non-issue with smart search algorithms, which is something you want to have anyway.

@Perig Gouanvic , what does this have to do with “evolution of the semantic web”? Could you expand on this a little more?

S

Shmerl Sat 8 Nov 2014 11:00PM

You want us to vote down your proposal all over again?

I'm not sure to whom you refer as "us", everyone votes here for oneself, unless you mean to represent some group of people? And it's the first time the vote is held on this proposal, so what do you refer as "again" to? The previous vote was on the limited idea of using to hashes for delimiting.

S

Shmerl Sat 8 Nov 2014 11:02PM

I guess I just don’t understand why whitespace is such a big deal.

Readability. The proposal actually describes what the problem is.

FS

Florian Staudacher Thu 13 Nov 2014 9:31PM

I see #hashtags as short classification of content with keywords. thus using more than one word seems "unintentional" to me.
Sure, the current parsing rules allow for #camelCase (and thus multiple words), but as a person with some experience in programming I would find it strange to complain about something like camel-case ;)

T

Timoses Fri 9 Sep 2016 11:51PM

So I suppose it's still not possible to search for multiple hashtags? Seems like a very important feature to be searching for just the posts that you'd like to look for.

In the end the syntactical phrasing shouldn't matter too much. The key is that any user should be able to search for just what they want to find. Thus, there should be a nice "Advanced tag search" view or something so that one could just add:

Search for: #energy #technology #sustainableenergy (Info: this will look for all posts that have all specified tags)
Also include: #solarpower #windpower (Info: all posts with any tag specified here will be listed)
Exclude: #nuclear (Info: no posts with any of these tags will be listed)

This does not cover all cases but offers a reasonable amount of flexibility that a person would want in a search.

How in the end this will be translated shouldn't bother the user much. If still programming style searching should be possible then just enable it for those advanced users (e.g. "((#energy & #technology) | #solarpower | #windpower) & !(#nuclear)"... simply using basic bool operators.

The biggest problem I see around here is that a focus is missing: User-friendliness. Think of the person that has absolutely no idea about programming, or doesn't know what electricity is but still uses a computer. If those users can use your interfaces well, then you've found the correct ones.