[swift-users] introduction, and bugs/wishlist/features

[Remko Tronçon]

Hi Ghostlands (and others),

> (TL:DR ALERT)

Thanks for taking the time to write down your feedback.

>  - OTRv3 (or whatever is the latest version by the time development
> begins, of course). OTR is not a modification of XMPP, and can be

OTR (or at least the feature that it provides) is something that is
definitely on our radar, and is in line with the goals we have for
Swift.
At the moment, we're waiting to see what happens in the XMPP community
with this on standardisation etc., so stay tuned.

>  - The next issue, and of lesser but still significant importance I
> think, is user-facing and transparent bug report forms.

We indeed want to have bug reporting that is easy for users. We have
run projects before where users reported bugs through the tracker, but
we noticed that the bug reports were most of the time incomplete, and
the users stopped responding when we asked for more details. This is
why we opted for a more interactive approach, where people can submit
bugs via e-mail, chat room, mailing list, ..., and that we make sure
the bugs entered in the system are usable for us when we get to
resolving them. We also hope that reporting through mail or the MUC is
easier for our users than having to deal with a bug tracker.

Better visibility of reported bugs makes sense. We used to have a link
to http://swift.im/tracker/ on the website, which lists all the
reported bugs and their status, but it seems it got lost during our
website transition. We'll look into putting this link back on the
site, and maybe giving the page some love so the layout is a bit
sensible again.

> typically my volume on my computer is about 2/3 of the way up. At
> this volume, the notification sound of Swift blares startlingly out
> of the speakers. This sucks. It is alarming every time.

I like the approach that Ghenghis suggested, and letting the
OS/Desktop Manager/ handle this. Not only from a practical perspective
where it requires less work and maintenance for us and avoids UI
design questions, but I actually think management of application
volume makes more sense on a global scale, where you have all
applications controlled together.

As Bernhard said, there is the question how far you want to go with
centralising app notifications (Growl, OS X, iOS centralise
everything), and whether you don't want to at least have some
shortcuts or expose these settings in the app itself for usability.
Food for thought.

>  - Lastly, account creation. While I'm decidedly uncomfortable with
> creating accounts via proxy for "security reasons", the truth is
> that many reputable and high quality, feature-rich servers *only
> allow creation by way of a client*.

Unfortunately, most servers that allow in-band registration tend to
not do any spam prevention (i don't know how well server
implementations support this), which has given IBR a bit of a bad name
(we regularly get organised attacks from IBR-enabled servers). The
general direction of server deployments seems to be to do registration
out of band, which is why it's not a frequently requested feature, and
which is why we have given it a low priority to implement this. Maybe
this has become more of a problem since jabber.org stopped taking
registrations.

cheers,
Remko