Improving and expanding hashtags usability.
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):
User can only follow a straight list of tags (i.e. following is defined with logical OR).
User can't filter tags for not following (i.e. not to see some content which has them).
Viewing options of followed tags in the UI are limited to either viewing all followed tags, or only one.
Search is limited to one tag.
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.
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).
Search should allow boolean expressions, the same way the following in the proposal (1-2).
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.
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
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||Option||% of points||Voters|
|Disagree||80.0%||16||RS- A D DU A|
|Undecided||0%||132||MS AA S CB GC AX PC|
20 of 152 people have voted (13%)
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.
Thu 30 Oct 2014 8:48PM
Useless. Just the result of a misunderstanding how tags work.
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".
Ivan Gabriel Morén
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.
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".
Sat 1 Nov 2014 7:06AM
I don't seem any need for this and I think it will just confuse newcomers more.
Sat 1 Nov 2014 7:06AM
I don't see any need for this and I think it will just confuse newcomers more.
Robin Stent - Outreach
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
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.
Poll Created Sun 2 Nov 2014 2:38AM
Create a standard syntax for multiword tags with whitespace Closed Mon 17 Nov 2014 2:05AM
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||Option||% of points||Voters|
|Disagree||66.7%||16||RS- DU A|
|Undecided||0%||129||MS AA S CB GC AX PC|
24 of 153 people have voted (15%)
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.
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
Steffen van Bergerem
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.
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 ...
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.
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.
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
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.
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)