Design of the Chat App

[LEDfan]

Hi

The ajax server is almost working, but I think it's important to first create the design of the app and port to AngularJS. That's why I have been working on a new design of the chat app. I have hosted a static owncloud page with the design on http://mockups-ledfan.rhcloud.com/ .

Conversation list The left bar is a list with the active conversations. It's a jquery accordion. When you click on a conversation, the options for this conversation is opened, and an new conversation window is opened. (not done yet)

Conversation windows When you click on "a" you can move the window. With "b" you can fix the window so it isn't possible to move the window or drop another window on it. With "-" you can minimize the window, and of course with "x" you can close the window. When you click on the conversation name, the conversation name converts into a input field and you can set the conversation name. (not done yet) Of course these letters need to be icons, but I haven't figured out how to do it.

Please share you thoughts. I hope you like it :)

cc @Kondou-ger @karlitschek @jancborchardt

[Niduroki]

I don't like the window design you're going for. IMO there should be only one conversation open at a time.

[LEDfan]

Yes but, there would be a new tab/fullscreen button. The App would have then a look like the Documents app and IRC. The view I'm new using can be used as a overview of conversations.

[Niduroki]

Why have two different views … I'd say we should only have one view.

[LEDfan]

I think it's easy to have different chats on the same window, especially when you are having chats with multiple persons in different conversations. When you have a conversation with multiple persons in one conversation I think it's indeed better to have full screen.

But why don't have both? Video and audio should only be available in fullscreen mode. (Like in Google Hangouts)

[Niduroki]

@jancborchardt opinion? :smile:

[j-ed]

@Kondou-ger I'm using a chat tool during my daily work to get/stay in touch with colleagues in other countries and I usually have 1-6 conversations open at the same time. I think restricting the application to only one chat is not the right way to go for most users.

[stefan-niedermann]

I would prefer a design like @Kondou-ger. This is a browser and i never saw "Window-Manager" implemented in JS that works well and performant.

What about a kind of tiling-Mode? So not windows, but you can open some Chats at the same time? If you have two, they would be left and right. If you have three, it would be left-top, right-top and bottom. and so on.

[Niduroki]

I'm okay with a tiling window manager.

[LEDfan]

I like the tilling window manager idea. I'll create a test.

I would like to remove the accordion, and just create a small list which can be opened and closed. Instead the buttons which are new in the accordion would be placed on a toolbar on the "windows" below the conversation name. Therefore I would like to use the Dojo toolkit.

[jancborchardt]

Hey, nice on the mockups!

First, I would say let’s not use jQuery UI at all. We want to get rid of it actually and by no means introduce more. It has lots of fancyness but actually we don’t want stuff to move around a lot. Also, let’s keep it very very simple. On the left a list of conversations, on the right the messages of the one selected conversation. Keep in mind we probably want to support inline pictures in the conversation etc. We shouldn’t implement window management or »fullscreen«.

Instead, the conversation list should have big entries (44px height at least) with the avatars of the participants, left-aligned. No need to have a name for the conversation. If there’s only one participant (1on1 chat), the avatar is on the left, and their full name next to it. When the current conversation is opened, there’s buttons for »Add person« and »Leave chat« aligned to the right.

In the conversation list there’s simple messages displayed. Newest on the bottom. Yours right aligned, the ones of others left aligned. A big input field on the bottom for you to put in new messages, including a send button.

Does that sound good? Best use the default classes like the News and Notes app. I can also mock this up more if you like but have not that much time at the moment. @Kondou-ger you want to take a stab at this?

[jancborchardt]

@LEDfan @Kondou-ger @j-ed @stefan-niedermann any feedback on the concept I described above?

Also @kadukeitor we should probably work together to make this and the »internal messages app« the one best chat app! :)

[stefan-niedermann]

Yeah, i totally agree, else i would have nag ;-)

[jancborchardt]

Also, how do we work on this? Using the apptemplates and Angular.JS, what’s the best way to develop an app nowadays @DeepDiver1975 @kabum @Raydiation?

And @LEDfan are you still in for working on this? :)

[j-ed]

As we all know a picture says more than 1000 words. That's my idea how it may look like:

[stefan-niedermann]

Well, "List of available Contacts, maybe taken from the contacts app" - Is this possible? I think the contacts should be owncloud users with an account.

What about this?

Maybe user should be able to give the conversations a better name, like "My School Class" - maybe it should not be called "Conversation" but "Chat Room"??

And: I think this app should kept simple: No "Insert Emoticons" - just change the String :-) to the image. No Print (if needed, add a css stylesheet @media print and use Strg + P), no "Take Screenshot" (Use Win + Print), no "clear conversation" (Do it with the X in the sidebar), no "Attach File" (drag & drop!)

[LEDfan]

First sorry for my late response....

@jancborchardt I really like the design you describe. I already have created a test page: http://mockups-ledfan.rhcloud.com/ . I have placed the Add Person and Leave button to the bottom. I can place them above, but in my tests it looks better at the bottom. I started with the design of @Kondou-ger, but I think it's better that the purple divs won't be purple :-)

I think for new it's better to only use owncloud users and no other public contacts.

Also I still like to work on this, but contributions are welcome :)

I think we should use AngularJS. The conversation list would be a controller, the chat window would be a controller, and the footer (The blue div at the bottom) would be a controller. These two makes use of the same scope variable with all the conversations and messages in. A simple push to the array would add a conversation or chat message.

[jancborchardt]

@LEDfan cool! Is that already in the repository here? The only thing I would say we should change is the footer bar: It should not be a footer bar over the complete width. Instead: The first entry in the left list should be »New conversation« and the footer should only be static on the right side. @Raydiation @DeepDiver1975 @Kondou-ger @kabum what do you think about the AngularJS / controller planning as described by @LEDfan above?

@j-ed @stefan-niedermann good on the mockups! I do however think that both proposals are a bit too complicated. We should get inspiration from simple chat apps such as Hangouts, Skype and Facebook chat. A conversation list (conversation can be with 1 or multiple people) to the left and the actual conversation in the main window is totally enough.

So, let’s start with the basics and iterate from there.

[LEDfan]

@jancborchardt no, it's just a static html page for testing. I have changed the footer, it makes it a lot better, and responsive without javascript :)

I'll new update the message list.

[j-ed]

I've just seen that someone has created a chat app for OC6 which might be of interest during the design phase: http://apps.owncloud.com/content/show.php/JavaScript+XMPP+Chat?content=162257

[stefan-niedermann]

i think the suggestion is nice, the chat is similiar to facebook and google, people are familiar with this design. could this be a second step? additional to the "full-screen"-app we discussed above?

[LEDfan]

I have updated the mockup, and added a mockup of the angular client so we can discuss it.

Features of the design:

• when the app is loaded a loading gif is show (I picked one from the w3, should be updated with the one used in the documents app etc), this simulates the client greeting the server etc. Normally this would be less than 2 seconds
• after the client is connected with the server - and there are no existing conversations in the database - then followed by a small text and a new conversation button. The text should be replaced by something more user friendly.
• after a new conversation is started the real chat app is shown. (I have moved the leave and invite button to the top, you'll see later why)
• you can click the simulate button so a chat message from the other person is simulated, in the input field at the bottom you can send chat messages
• when the user leaves the latest conversation, the empty panel will show up.
• when the client is loaded with smaller dimensions the left bar with conversations is hidden and the active conversations will show up in a select in the header.
• when the height of the client is small (like on a tablet) and there is focus on the chat message input field, the owncloud header will disappear. I have chosen to do it that way because the keyboard on android takes a lot of space. Without this the latest messages can't be read.
• when the width is very small the header's height is doubled so there's more place for the buttons.

Angular design:

• I have made 1 controller of the whole page, so there is no need to connect the $scope variables of the different controllers
• I have created an object with all the UI functions (like show,hide header etc)
• and an object for util functions, like generate a session-id etc

I have a few questions on how to do the rest of the angular work:

• were will we make the ajax requests to the server? In the controller or in a separate class like the UI functions? I prefer the last option, but I don't know all the options of angular.
• will we use $http.post or $.post? This depends off course on the question above.

I hope you like it :) cc @jancborchardt @Kondou-ger

[fossxplorer]

I agree with @j-ed and @stefan-niedermann on support for GTalk/Hangout/Facebook chat alike chat window that isn't full screen. That might enable the OC user to do his tasks inside OC while chatting with another user. Hope it's possible to implement such design.

[jancborchardt]

Hey @sualko, you are the developer of the JS XMPP app in the ownCloud appstore. It would be cool if @LEDfan and you can collaborate on one chat app. If that’s polished eventually we might even have it in the shipped version! :)

[sualko]

you are the developer of the JS XMPP app in the ownCloud appstore

I know :-).

I think the approach of our two projects is totally different, because the above discussion is about an isolated oc chat. On the other hand my application is a full supported XMPP client with the need of an extern Jabber server. But maybe we could use one ui with different backends? I'm open for discussion.

[Niduroki]

Having a look at this project's TODO XMPP support is planned – for the far future :smile:

[sualko]

I think my feature list covers this todo list very well :smile:. So maybe it's a good idea to join this projects.

[jancborchardt]

@sualko I think we shouldn’t make a differentiation between an "internal" ownCloud chat app and external contacts. Look at Facebook private messages for example – you can chat with people on Facebook, but also send and receive from/to email addresses.

The »Chat app« should be an integrated, multi-purpose communication app. @LEDfan what do you think?

I really think it’s more beneficial for ownCloud if we collaborate on apps/projects like these. It’s always difficult to keep up the pace when there’s only one maintainer. And it’s more fun working together on one solution which will be shipped rather than on 2 half implementations. :)

[LEDfan]

I think we should create one app, with several backends and serveral clients but with one GUI. By using angular, the client could stay almost identically for each backend. The UI and maybe the util class in classes.js could stay the same and be used by both angular controllers. In the util class for example the throwNotification() function could stay the same. In the PHP template we could change the controller name for angular and load only the files needed for this client.

Maybe we should replace the Websocket backend by the XMPP backend?

@sualko What is the advantage of having a chat GUI in the existing OC GUI?

[jancborchardt]

@LEDfan @sualko I think it’s really useful to have active chats also present as small widget on the bottom right also when in other apps. That’s one of the big points why Facebook and Gmail make it so easy to chat with people wherever you are on the platform.

[jancborchardt]

@LEDfan @sualko @Kondou-ger Alessandro (@zimba12) is organizing for ownCloud to participate in Google Summer of Code again this year – this time as own organization. I think a proper chat app would be a great project. @zimba12 is it possible for @LEDfan and @sualko to collaborate as students?

@Kondou-ger @Raydiation are you interested in mentoring this?

Check the other proposals at https://github.com/owncloud/core/wiki/GSoC,-GCI-and-OPW Cheers!

[Niduroki]

From when to when will gsoc run?

I'm pretty busy with university and some other projects right now.

[sualko]

@LEDfan The advantage is, that you can chat on every page.

But before we continue, I think I should say a few words about my project: It's designed as a framework which can be included in every webpage. So there is a edition for Diaspora or SOGo. From this background I'm interested in developing a application with a weak binding to oc.

But I'm also interested in a collaboration, because I think it could be fun.

Regards Klaus

[LEDfan]

@jancborchardt unfortunately I think I can't join the gsoc since I'm -18.

@sualko I understand the advantage of chatting on every page but I think an native app in owncloud would be imported too. What do you think about creating one app, using my design and your design (native app and integrated in every page) and having several backends, which the sysadmin can choose out but the user doesn't really have to think about?

[sualko]

I think we shouldn't confuse the user with two designs/apps/interfaces. The problem with your design is that the user must make a decision between chat and work. So he can only chat or he can work with oc, this is not user-friendly.

Also I think there is no use case for an internal oc backend, because who will use this chat? A small family installation with 10 members? I think no. A chat makes only sense in a big environment with hundreds of users and in this case it shouldn't be a problem to install a xmpp server. There are even more disadvantages with an self-made chat server, like maintenance or performance.

[jancborchardt]

@sualko @LEDfan what’s the problem with having both? The chat can be on every page, but some people might find it annoying and rather use a dedicated app. Other people could only use the chat widget on every page. The contents would be the same.

[jancborchardt]

cc @silverbucket about if it makes sense to use http://sockethub.org here.

[silverbucket]

Hey guys, just read through this thread after @jancborchardt pointed it out to me. What you're describing sounds like the exact same type of problem I've been working on solving with Sockethub [http://github.com/sockethub/sockethub]. Sockethub is a polyglot messaging backend. It's built with node.js and uses WebSockets to communicate with the front-end.

In fact I'm actually working on the front-end app right now here at hackerbeach. The app itself is completely decoupled from any protocol knowledge and all of the communication is done through generic JSON objects describing the message (based on ActivityStreams [http://activitystrea.ms]. Messaging backends currently supported are XMPP, IRC, Facebook, Twitter, Email. Of which you could use any combination of them. I also would like to add WhatsApp support once I get the front-end app working with XMPP & IRC.

Maybe there's room here for us to work together? The app I'm working on is also written in AngularJS. There are a few simple Sockethub wrappers for AngularJS as well (in the sockethub-client [http://github.com/sockethub/sockethub-client] repository).

Interested in your thoughts!

[sualko]

@jancborchardt As I said, two frontends are confusing and doubling the work...

[silverbucket]

@sualko not sure if your response was regarding sockethub or not, but just FYI sockethub is a polyglot messaging backend, no front-end dependencies.

[sualko]

@silverbucket No it was for Jan. I just updated my post.

[LEDfan]

@sualko I understand your critics on this chat app which uses it's own chatting protocol, but the whole point why we created it is that it must run on every OwnCloud installation, and can be installed by just clicking the "enable" button.

I'll write down my ideas ASAP.

[jancborchardt]

@LEDfan @sualko (also cc @DeepDiver1975 for the Mail app)

The goal of the »Chat« app for ownCloud should be that it is a generalized communication app. Instant messaging, communication of people inside the ownCloud, email – it’s all the same: person- or group-based communication.

Much like Skype or Hangouts, the center should be a list of people and groups which you often communicate with (collaboration with the Contacts app is obvious here cc @tanghus @babelouest @jbtbnl). Everything I talked with a person over whichever protocol (be it IM, or email, or with other people on the ownCloud or whatnot) should be available there. Hence there should be a dedicated app for sure.

The bottom-right widget has its place as well of course, so you are easily able to chat wherever you are in ownCloud. Much like in Facebook where you have both the private messages area and the chat widget.

I think it’s important that we understand it should not be a simple »Chat« app. Then we would have an app for »Chat«, for »Email«, for »ownCloud Messages« and it’s very difficult for people to remember where a specific conversation was. And especially since we have a Contacts app and know which handles and addresses belong to whom, we can easily combine that.

Does that clear things up?

[LEDfan]

I understand the importance of integration with the contacts app. So if you press the "new conversation" button you would have to choose first a protocol (XMPP, my protocol, E-mail) and then have to choose a user which is stored in the contacts app?

[jancborchardt]

@LEDfan no, you would first choose the person of course. The protocol is less relevant. And there is only one entry per person, not multiple ones based on the protocols. When a contact only has one messaging protocol handle, then that one is used. Otherwise we could default to one (one we notice the user often uses for example) but still offer to change it or send individual messages via other protocol.

[LEDfan]

Yes that's what I meaned... Thus in the contacts app there would be a setting for each contact how two conversation with it? So to email with someone an email address must be stored in the contacts app. To XMPP with someone the jabberid must be provided etc? And off course a mix of them would be possible. And if it is a owncloud user you can use the owncloud chat protocol

[jancborchardt]

No, the setting would not be in the Contacts app. The Chat app would get all info from Contacts and then inside Chat that would be decided. Like when you have an existing conversation with someone over email, that would get used. Of course in the beginning you would have to choose the default protocol for that person. But say, when that person messages you with a specific protocol, for answering the app should automatically default to that same protocol.

[jancborchardt]

The send button could by default say »Send (via email)« and have a dropdown on the right if there are other protocols that contact has defined. Then you could change to Send via XMPP or whatnot.

[LEDfan]

I understand. But the info on how to contact the person would be stored in the contacts app right?

[jancborchardt]

@LEDfan yes, as it is now. :)

[LEDfan]

Do you think the design of the app in this repo: Would be sufficient to view email conversations? Off course some small adjustment need to be done. (Like a larger input field)