Integrating with Pidgen/libPurple/Adium
Yuuguu is a wonderfully useful product, but its interface is abhorrent. Pidgin does the contact thing really well... It even allows me to integrate my Skype (right click on a Skype contact and I can initiate a call, chat, etc). Yuuguu would be sooooo much better if it plugged into the already superior, and open sourced, interfaces, and kept working on the screen sharing it already does so well.
7
people like this idea
I like this idea!
Tell me when this idea gets some attention.
The more people who like this idea, the more it gets noticed.
The more people who like this idea, the more it gets noticed.
Create a customer community for your own organization
Plans starting at $19/month
-
Inappropriate?Yeah, i would definitely be more inclined to purchase yuuguu if it integrated with pidgin. Right now the yuuguu client is just horrid.
-
Inappropriate?I'm afraid that integrating with Pidgin isn't feasible.
Pidgin is written in C whereas Yuuguu is written in Java. The only way that Yuuguu could be integrated into Pidgin is to scrap the entire client at which point it ceases to be Yuuguu.
We are planning on overhauling the Yuuguu user interface in the future and we have already implemented Skype integration. -
Tell me one java app that people use on a daily basis? Yes, java is an easy way out to make a cross os app, but as far as usability, they are normally horrid for daily use. -
Again, *why*, and what *specifically* about Yuuguu. I care quite little about how bad Java apps may or may not be in general - I want you to tell me what is horrid about Yuuguu. As far as user experience is concerned, the technology could be pigeons and bits of wet string. I know that your basic Java 'Metal' Swing UI usually looks pretty clunky, which is why we didn't use it. In fact, we modelled our client on the (then) popular and emerging AJAX based 'Web 2.0' sites. So you are welcome to hate it with a passion, but please be specific if you want to tell me why, and just be aware that at least we gave thought to UX and we did not pick the simplest route available to us. As I say, you are welcome to say that you don't agree we got the decisions right for your liking. Be interested in the detail.
I think Mike's point was simply that the engineering for us to switch from one technology binding to another would be prohibitive, rather than a defence of what we've done. We picked Java because it is cross platform (though not easily for our purposes, we have a fair amount of native code we've had to write and port) and we liked it
- ta - Al -
Look below, i did give details. I also think my points about java are still on par. If companies could easily do what your saying to make java work well, then why isnt it being done? Because it cant be done well. Thus no successful company is doing it. -
Open Office is used by a lot of people on a daily basis and that is written in Java as far as I know...
Your points are good and we'll take them onboard as we work on the interface. Striking the balance between adding new functionality & improving the GUI is something we aim to get right.
Regards, Phill. -
Inappropriate?We're just working on tidying up our Skype integration, so that just like pidgin, you can link contacts with Skype ones and have a 'Skype' button appear. You'll then use Yuuguu chat, control and sharing, with a voice channel using Skype.
I'm interested in what is meants by 'abhorrent' and 'horrid' in the above discussion. Those words tell me you're not happy. They do not tell me why. -
Inappropriate?The layout is just poo and not easy to read and keep track of conversations. Even the font looks very bad and unclear (typical with java apps). I couldnt really even use it to long to see how it works with multiple conversations. Here is my typical pidgin window: http://screencast.com/t/XbMVveFxp6v
As you can see, I have a lot of conversations going (i do a lot of irc as well, which is always needed in a multi chat app) and they are all logged and easy to switch between and view past conversations. A you can see, the text is easy to read and the layout is clean. Ah, you also do not have any grouping or ways to hide offline users.
There are just tons of UI issues, the biggest probably being the font quality, but the others listed above are almost just as important. -
Inappropriate?Mark - thanks for your detailed feedback. Constructive criticism is always hard to hear, but very valuable! thanks once again.
-
Inappropriate?I think the biggest issue is that the world does not need another stand alone application that we all need to maintain that already does what is already being done. Especially one that does not handle their repositories correctly (see my other UNANSWERED posting regarding signing keys not being supplied) and is not in the standard repositories of any major Linux distro. Co-operation always works better than isolation. I realize that you application has additional features, but why are you re-inventing a wheel that works perfectly to add features on... instead of just adding on.
And now, the real issues comes out. You guys are now finding out why Java never replaced C++ as a cross platform language... it does not work with anything else. As a matter of fact, both Python and Ruby make better cross platform programming languages than Java does. Both of these languages can embrace and extend the existing C code, as well as use the native fonts on the system.
I am finding that the Linux version of the product is looking pretty awful compared to native applications, and as a Linux user, I am not used to as much spit and polish as a Windows user would, let along a Mac user.
I can't speak for others, but I am loosing confidence in the YuuGuu team to deliver on the promise of a great idea.
I’m sad
-
Inappropriate?I think I read your unanswered question, but didn't know the answer. The way we work our free forums is that the dev team members (note: none of us are smiley, database-backed service droids) have a look over them, and generally answer quite quickly if we have anything useful to say. It's also holiday season, and that doesn't help.
As to the rest of your post, let me try and summarise back to you how I read it, in case I got it all wrong:
1. You would much rather we integrated with an existing IM client than make our own
2. Your opinion is that Java never replaced C++ as a cross platform language
3. You claim it is a fact that two recent and popular computer programming languages are better suited to developing Yuuguu than the one(s) we told you we actually use
4. You think that using either language would give us advantages you dont think we currently have
5. You think the linux UI looks pretty awful
6. You don't think we are delivering on our original vision
All in all, interesting stuff. I can understand (1), and our chief tech officer has some sympathies with that point of view. But we didn;t want to jump that way back in the day for various reasons. We chose a different route to 'co-operation': we implemented multi-protocol support and integrate with GTalk, MSN, Skype etc. The IM client part of our product for sure isn;t as nice as the best of breed ones at present. I can see us improving ours, but I cant see us becoming a bolt-on to adium/pidgin/what have you.
(2) and (3) I don't wish to delve in to here. I have formed plenty of opinons about programming languages over my 25 years in software development, and have the battle scars to prove it. Buy me a pint at the next conference we're both at and we can share IT war stories. But if you can provide any evidence for those languages being better (note: I have heard this before, just the once or twice, so I am talking about hard studies with proper numbers behind them), then I'm interested as a professional developer. Please share them - alan dot mellor at yuuguu dot com.
(4) and (5) more interesting; I think I mentioned that we write a lot of native code for each platform we support. As such, we are not dependent on the features (or lack thereof) of the Java language (or any language we choose) so much. Some things might be harder, and so we might not do them as quickly. Can't say Im familiar with linux enough to address this 'native fonts' issue you mention, but I'll raise that in out next dev meeting and se if anything can easily be done. It is a shame that you think the linux version isn't nice enough - but given that your key issue seems to be 'scrap it and use another IM client as a base', I'm not sure its worth asking you what you would like to see different in *our* client. We generally get 'okay-ish' feedback on our client. Most people find it usable and useful - and, indeed, pretty enough - for their needs, but we are definitely aware it is not the best right now.
I think I disagree with your summation (6) though: I think we *do* deliver on what we promised - that is to be a very usable all-in-one team collaboration tool primarily, with cross platform share and control, group share and control, an easy workflow for ad-hoc, unplanned meetings, telephone conferencing, skype VOIP, a no-download web based capability, a damn sight cheaper than our nearest player in this space, easy (win/mac) installs, typically zero-config. We have done that. We continually improve that. I'll give you that we haven't done it the way you would like to see. I'll even give you that some of what you say has merit. But we still probably wont jump that way
Anyways, thanks for your comments - all thought provoking. Hope this reply finds you well.
Al -
Inappropriate?Uh, when did a response of "okay-ish" become a good one? To me, that sounds like 5 out of 10. Do you actually consider that to be acceptable when clients give you feedback? I sure dont. Do you think the other multi billiion dollar companies that made their chat clients chose C++ over Java when Java was the better solution? I really dont think any scientific reports is really needed to uphold the java versus C++ argument as all you have to do is open your eyes and look at what people use on daily basis. To me and most of the world, feature sets dont really mean anything if you have a poor UI.
I’m frustrated
-
Inappropriate?Mark,
We accept that all the major IM networks use C or C++ for their clients and that this helps them to develop a slicker UI. However these UIs are only run on a single platform (usually Windows). If an official client is available on other platforms the UI (and often functionality) is completely different.
One of the goals of Yuuguu was to make a single client that would run on all platforms and provide a consistent user experience. The client UI is overdue an overhaul but at the moment we are focusing on getting features finished that have been in the pipeline for some time and fixing the mess that Yahoo have dropped us in with their protocol changes.
Michael -
Inappropriate?Yuuguu provides a spectacular, unparalleled capability. That is why, despite all the complaining and frustration, the users are not going elsewhere, but continuing to complain and act frustrated :)
Language choices and UI choices, etc. are stuff and fluff. We are not going to all agree because we have differing requirements and goals and evaluation criteria. The development team and the company naturally want interface uniqueness and visibility and cross-platform consistency and ease of development and ability to use cheaper Java devs instead of expensive C++ hackers. Linux users naturally want native look and feel and interoperability with the rest of the desktop and less intrusive interfaces and more control over behavior.
If the company really wants a community of pleased non-windows users, it will pay attention to their wishes. Probably by providing a public API to the screen-sharing functionality and letting the community integrate it into the desktop the way they want. Of course the company will have to consider how to provide a path to making some money out of this... But not pleasing the (or a) user community is a way to ensure complete rejection of the product by the community as soon as the first alternative comes along. Don't wait for us to get a chance to go elsewhere - take advantage of being pretty much the only and the first and the best and lock it in for the long term. And don't forget to consult the community before you settle on an API, if you don't want to hear a lot of subsequent whining.
And please, please, publish keys for your repos. That's just embarrassing for you and causes me to avoid automatic updates, so I end up not using the versions of the product, that you want me to use - you worked too hard on them to let them sit unused in your unauthenticatable repo. If you need help creating and publishing a key, just ask - I am sure you will get plenty of volunteer assistance.
---Sergey
Loading Profile...


