Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Appalling Usability #1197
So having read the bugtracker, there are a number of things that keep popping over and over. Mainly:
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.
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" @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.
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.
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.
Do you also disable all email accounts when you do not want email? And log
I agree with the devs firm hand on this project, look at almost any desktop
The developers make the source available for everybody to make their own
I close my browser
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 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:
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. :-)
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.
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.