New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Appalling Usability #1197

Closed
sereforg opened this Issue May 14, 2015 · 8 comments

Comments

Projects
None yet
4 participants
@sereforg

sereforg commented May 14, 2015

So having read the bugtracker, there are a number of things that keep popping over and over. Mainly:

  • No presence support (great exposition by @Yajo on #236)
  • No status indication (note the last comment by @devurandom on #440)
  • No support for full set of configuration options (e.g., explicit setting of hostname / port, with a fantastic summary by @SafwatHalaby on #962, there are also other issues concerning TLS use, etc.)
  • Multiple support requests on the bugtracker, and subsequent complaints (including my own at #1196)

Quickly put, the problem is not so much the lack of those features but the reason they are lacking: which is that the development lead waves them away because, I paraphrase, "they don't fit with the vision".

That's cool, but I respectfully suggest that the above is not a viable long-term attitude, and not one that's going to go down well with employers looking at a candidate's Github.

As for me, I tried this application. It has some good things: it supports carbon copies and MOM, and feels responsive (unlike Xabber 2.0, sadly). Sadly, given the lack of leadership and project management skills shown here by the main developer, there is no way I would be relying on this application in the long term. It has now been uninstalled.

@strb

This comment has been minimized.

Contributor

strb commented May 14, 2015

If you don't like it, fork it.

@strb strb closed this May 14, 2015

@SafwatHalaby

This comment has been minimized.

Contributor

SafwatHalaby commented May 14, 2015

Hello. I think that many of your points are valid, but I also understand the viewpoint of the devs, allow me to set a "middle-ground".

@strb , I think that the right approach would be reaching an understanding, and not just closing the issue, that's especially true considering the fact that @sereforg 's points have been mentioned numerous times before.

The vision

"The vision" @iNPUTmice has in mind is an app that is as simple is it could possibly get, sort of "The Whatsapp of XMPP". A huge part of the simplicity of Whatsapp/Conversations stems from the fact that the user is not bothered with the connection, it's sort of like a good behaving pigeon: You give it the message and you forget about the rest, it'll eventually reach the destination.

Almost all issues the devs constantly reject revolve around that exact ideology: "You shouldn't care about the connection" (tm). Status updates, Presence, and logging out are all "caring about the connection".

While you said it ironically, those features indeed "don't fit with the vision". I rejected that idea at first but now I see the genius behind it. It allows you to focus solely on what you came for: chatting. You only care about typing the message, something else takes care of the transportation for you. It's sort of like telepathy: You just say something, your peer will eventually hear it, and you'll know it when they hear it, and that's it, no need to deal with what's behind the scenes.

If you understand this mindset, it'll be clear why the developers decided to let go of status updates and presence. They just want a "telepathy" app. A pipe that you shout into, and the other side eventually hears. Simple, beautiful.

Host/ port

Regarding host/port settings: Any public server shouldn't need an explicit setting of hostname / port because that is handled by SRV records. Private, dns-less servers do sometimes need this, the developers resolve that by saying "get a dns", or by explaining that Conversations is aimed at the casual user who'd never connect to a non-public server, and that supporting exotic settings only encourages fragmentation. On the other hand, adding the feature is dirt-cheap, and private servers WANT to be fragmented.

Exit button

While I don't have a strong opinion regarding the "host/port" decision, I think that THIS is where the developers are totally wrong, I argue that it's a mis-interpretation of their own vision.

Let us read that again: "The user shouldn't be bothered with the connection". In other words, only the higher-level aspects should matter. That is, only sending and receiving messages should matter. Hold on, what if I don't want to receive a message right now? That's no longer a connection-level issue that the user shouldn't deal with, that's a messaging issue.

"The user shouldn't be bothered with the connection" does not lead to "The user shouldn't have the ability to shut their ears off for a while". Yes, I know there are various ways to shut those ears: Disconnecting 3g, force closing the app, hitting "disable all accounts", etc. but all those methods suffer their cons.

Fixing this is as simple as fixing (and perhaps renaming) the "disable all accounts" button. It should be a global switch that simply overrides the individual account settings and simply logs you off the grid. Clicking it again should turn off the global switch and re-respect the individual account rules.

@andersruneson

This comment has been minimized.

Contributor

andersruneson commented May 14, 2015

Do you also disable all email accounts when you do not want email? And log
out of hangouts when you do not want to receive messages? And pull out to
sim when you do not want phone calls or SMS?

I agree with the devs firm hand on this project, look at almost any desktop
xmpp application and you will see the result of all "meaningless" features
that everybody MUST have: they are bloated, the real functionality is buggy
and they are a pain to maintain.

The developers make the source available for everybody to make their own
remix, if so many people want your features they will love your version of
it! Go create!
On 14 May 2015 19:20, "Safwat Halaby" notifications@github.com wrote:

Hello. I think that many of your points are valid, but I also understand
the viewpoint of the devs, allow me to set a "middle-ground".

@strb https://github.com/strb , I think that the right approach would
be reaching an understanding, and not just closing the issue, that's
especially true considering the fact that @sereforg
https://github.com/sereforg 's points have been mentioned numerous
times before.
The vision

"The vision" @iNPUTmice https://github.com/iNPUTmice has in mind is an
app that is as simple is it could possibly get, sort of "The Whatsapp of
XMPP". A huge part of the simplicity of Whatsapp/Conversations stems from
the fact that the user is not bothered with the connection, it's sort
of like a good behaving pigeon: You give it the message and you forget
about the rest, it'll eventually reach the destination.

Almost all issues the devs constantly reject revolve around that exact
ideology: "You shouldn't care about the connection" (tm). Status
updates, Presence, and logging out are all "caring about the connection".

While you said it ironically, those features indeed "don't fit with the
vision". I rejected that idea at first but now I see the genius behind it.
It allows you to focus solely on what you came for: chatting. You only care
about typing the message, something else takes care of the transportation
for you. It's sort of like telepathy: You just say something, your peer
will eventually hear it, and you'll know it when they hear it, and that's
it, no need to deal with what's behind the scenes.

If you understand this mindset, it'll be clear why the developers decided
to let go of status updates and presence. They just want a "telepathy" app.
A pipe that you shout into, and the other side eventually hears. Simple,
beautiful.
Host/ port

Regarding host/port settings: Any public server shouldn't need an explicit
setting of hostname / port because that is handled by SRV records. Private,
dns-less servers do sometimes need this, the developers resolve that by
saying "get a dns", or by explaining that Conversations is aimed at the
casual user who'd never connect to a non-public server, and that supporting
exotic settings only encourages fragmentation. On the other hand, adding
the feature is dirt-cheap, and private servers WANT to be fragmented.
Exit button

While I don't have a strong opinion regarding the "host/port" decision, I
think that THIS is where the developers are totally wrong, I argue that
it's a mis-interpretation of their own vision.

Let us read that again: "The user shouldn't be bothered with the
connection"
. In other words, only the higher-level aspects should
matter. That is, only sending and receiving messages should matter. Hold
on, what if I don't want to receive a message right now? That's no
longer a connection-level issue that the user shouldn't deal with, that's a
messaging issue.

"The user shouldn't be bothered with the connection" does not lead to "The
user shouldn't have the ability to shut their ears off for a while"
.
Yes, I know there are various ways to shut those ears: Disconnecting 3g,
force closing the app, hitting "disable all accounts", etc. but all those
methods suffer their cons.

Fixing this is as simple as fixing (and perhaps renaming) the "disable all
accounts" button. It should be a global switch that simply overrides the
individual account settings and simply logs you off the grid. Clicking it
again should turn off the global switch and re-respect the individual
account rules.


Reply to this email directly or view it on GitHub
#1197 (comment)
.

@SafwatHalaby

This comment has been minimized.

Contributor

SafwatHalaby commented May 14, 2015

"Do you also disable all email accounts when you do not want email?"

I close my browser

And log out of hangouts when you do not want to receive messages?

yes. I don't use the mobile hangout. I close my browser with the Desktop hangout.

And pull out to sim when you do not want phone calls or SMS?

Silence mode / flight mode, depending on what I want.

Edit: I use silence mode because in flight mode, missing calls are forever lost and you never get notified about them. If flight mode were perfect, I would have always used that instead. Conversations needs a flight mode.

@SafwatHalaby

This comment has been minimized.

Contributor

SafwatHalaby commented May 14, 2015

I edited the post slightly. You are right about the meaningless features, this is why I agree on not having most of them. But the "disable all accounts feature" is not meaningless, and it's already in the app, but it's broken.

@sereforg

This comment has been minimized.

sereforg commented May 15, 2015

@SafwatHalaby while your comments are spot on, as I see it the main problem with this project, and the reason it's going to fail, is not in the specific issues but in the way they're handled. That point wasn't clear in my previous post, for which I apologise.

It is often heard, in usability circles, that you "should not listen to your users". This is a soundbite and as such its primary aim is to catch attention, not to convey the whole truth. In reality, not listening to your users just means that they will find someone more interesting to talk with--if you are "selling" a product this is suicide.

The real issue is that users will typically tell you what they perceive to be the problem or, more often, they will just jump straight to telling you what they think should be the solution. In most cases, you as the developer, project manager, etc., will have a much better vantage point and understanding of the product than the user, so you may (and should) realise that what they are saying is not what they are experiencing, and what they say they want is not what they actually want, which in turn may not be what they need.

But in any case, if a user is complaining, you have a problem. The problem may be the user or the product. Some people may be way off at the edges of your target users normal curve, such as let us say someone trying to use the wrong tool for the job (imagine attempting an architectural drawing in Excel?); others might be predisposed against your product or company or yourself for reasons unrelated to the product (maybe you "stole" their girlfriend in college? or they used to work for your company and got laid off?); others may just feel insecure or be purely seeking some social interaction. Point is that yes, there are many cases where a user reports a problem when there is no actual problem with your product.

If you have lots of users complaining about the same aspect of your product, on the other hand, it's much more likely that there is an issue with your product somewhere there.

However, whether it's the user or the product, you have a problem in any case.

If you're lucky, the problem is a bug or something technical that can be fixed. You fix it and everybody is happy.

If you're not so lucky, you still have to deal with the users. You do that by:

  • Listening to them. Do not believe the soundbites. Nobody likes people who don't listen.
  • Understanding their problem. Whether it may be technical (functional or non-functional), perceptual, emotional, etc., you need to know why they're complaining to you.
  • Gaining their trust and building a rapport with them. Your users are not your enemies. They are there to help you achieve your goals--whether it be to become rich, famous, respected, ... You need to show that you understand them and care about them.
  • Persuading them of your solution. So you need to negotiate. You may think you've got the best solution in the universe, and you may be right, but unless you can convince your user of that, your problem is not solved. Sometimes you may need to go for a (subjectively or objectively) suboptimal solution as a compromise. In rare cases (and those are rarer than you think), there may be no compromise possible--even so, you still need to persuade your users to agree with your assessment. To retake the example of Mr. Excel guy above, you may suggest to them that AutoCAD would be a much better tool to do the blueprints of their new house with, but you must communicate that on the other hand Excel would be just the perfect tool to work out how much the house is going to cost.

Remember, even though you may be designing a product to solve a problem you have, unless you intend to be the only user (in which case you don't make your project public) you'll need to take everyone else into account.

And this is what is not happening here. For instance when quaint Mr. @strb tells the user to fork off (if you would pardon the pun) he's not a) listening, b) understanding, c) building a rapport, or d) persuading, so clearly no favourable outcome is possible. Instead the user may decide that the only advantage of the product (implementing a couple new-ish XEPs: MOM and carbon copies) does not offer enough of a competitive edge compared to other solutions such as Xabber, and may decide to support the competitor instead, perhaps sponsoring the missing features.

Some of us have learned from our own mistakes. :-)

@SafwatHalaby

This comment has been minimized.

Contributor

SafwatHalaby commented May 15, 2015

Thanks. That's a very interesting read. I think you nailed the problem: It's not a technical problem; The product might be technically superior, but something is broken with the way the complaints (which, as you mentioned, often stem from users not knowing what they want) are being handled.

@strb

This comment has been minimized.

Contributor

strb commented May 15, 2015

I'm not sure what you are hoping to achieve here and I'm afraid there's nothing I can say to satisfy you. These issues have been discussed and the maintainers have made their stance clear.

It may have come across that way, but I really wasn't trying to be snarky when I invited you to fork the project. If you feel strongly that you could do a better job, by all means, fork the project, and develop it as you please. After all, that's the beauty of open source. We don't have to agree with you for you to be able to get what you desire. But please refrain from raising the same discussions over and over again. As far as the technical arguments go, your elaborations are not adding anything new. Just because you may not have been part of those past discussions yourselves doesn't mean that the arguments you are making have not been raised -- and considered -- numerous times before.

And as far as your opinions about the management of this project go, this is absolutely the wrong place for such accusations. This is a bug tracker, not a discussion forum. And to put it bluntly, @sereforg, you are way out of line, and your patronizing tone is not appreciated. Do not mistake disagreement about direction for poor management. Do not mistake lack of willingness to go through identical discussions time and time again with poor leadership.

I am locking this issue, because, quite simply, there is nothing more to say. As it stands at the moment, the features you are asking for are just not going to happen. I suggest you make peace with that fact. If you wish to continue this discussion, please do so in a more appropriate venue, e.g. our MUC or via email.

@siacs siacs locked and limited conversation to collaborators May 15, 2015

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.