Loomio

Improving and expanding hashtags usability.

S
Shmerl Public Seen by 387

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

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

@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

@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

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

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

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

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

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

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

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

@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

Chris started a proposal Thu 30 Oct 2014

multi-word hashtags should be enabled by requiring two hashes Closed Sat 1 Nov 2014

Outcome
by Chris Tue 25 Apr 2017

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.

Agree - 2
Abstain - 2
Disagree - 16
Block - 0
20 people have voted (13%)
C

Chris
Agree
Thu 30 Oct 2014

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

S

Shmerl
Disagree
Thu 30 Oct 2014

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

RF

Rasmus Fuhse
Disagree
Thu 30 Oct 2014

Don't like the syntax. See comment

JH

Jonne Haß
Disagree
Thu 30 Oct 2014

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

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

N

NicoAlto
Disagree
Thu 30 Oct 2014

G

goob
Disagree
Thu 30 Oct 2014

I think this would cause problems as suggested above.

JR

Jason Robinson
Disagree
Thu 30 Oct 2014

A

Augier
Disagree
Thu 30 Oct 2014

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

DU

[deactivated account]
Agree
Thu 30 Oct 2014

#"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".

JS

Juan Santiago
Abstain
Thu 30 Oct 2014

IGM

Ivan Gabriel Morén
Disagree
Thu 30 Oct 2014

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

+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

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

KAK

Karthikeyan A K
Agree
Sat 1 Nov 2014

Looks bit confusing, but its okay

A

Asher
Disagree
Sat 1 Nov 2014

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

A

Asher
Disagree
Sat 1 Nov 2014

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

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

Confusing and unnecessary.

SVB

Steffen van Bergerem
Disagree
Sat 1 Nov 2014

X

Xophael
Disagree
Sat 1 Nov 2014

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

DM

D. Moonfire
Disagree
Sat 1 Nov 2014

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

@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

@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

@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

@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

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

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

RF

Rasmus Fuhse Thu 30 Oct 2014

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

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

Can someone explain why we even need tags with whitespace?

DU

[deactivated account] Thu 30 Oct 2014

"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

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

@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

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.

A

Augier Thu 30 Oct 2014

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

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

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

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

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

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.

A

Augier Thu 30 Oct 2014

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

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

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

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

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.

A

Augier Thu 30 Oct 2014

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

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

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.

A

Augier Thu 30 Oct 2014

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

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

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

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

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

"#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.

A

Augier Thu 30 Oct 2014

“#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

@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

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

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

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

A

Augier Fri 31 Oct 2014

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

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)
A

Augier Fri 31 Oct 2014

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

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

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

@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

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

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.

A

Augier Fri 31 Oct 2014

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

@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

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

@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

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

@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

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

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

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

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

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

Shmerl started a proposal Sun 2 Nov 2014

Create a standard syntax for multiword tags with whitespace Closed Sun 16 Nov 2014

Outcome
by Shmerl Tue 25 Apr 2017

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.

Agree - 7
Abstain - 0
Disagree - 16
Block - 1
24 people have voted (15%)
S

Shmerl
Agree
Sun 2 Nov 2014

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

JR

Jason Robinson
Disagree
Sun 2 Nov 2014

JR

Jason Robinson
Block
Sun 2 Nov 2014

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

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

N

NicoAlto
Disagree
Sun 2 Nov 2014

JH

Jonne Haß
Disagree
Sun 2 Nov 2014

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

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.

G

goob
Disagree
Sun 2 Nov 2014