search

banji-project / ring-issues

Old issues before it was moved to kde.org
0 stars 0 forks source link

GUI: Ongoing status (removing the old GUI completely) #18

Closed Elv13 closed 6 years ago

Elv13 commented 7 years ago

Timeline:

image

Ringing call:

image

The widget at bottom tracks the call progress and print relevant error if it failed

After the call ended:

image

In call:

image

Persistent widget to hang up current call while looking at the chat or other users:

image

Live search with username lookup:

image

Just press enter and you can already edit the contact, no need for the dialog:

image

The scrollbar now really works

image

The search with my test dataset:

image

A video from yesterday (dark theme, sorry)

https://www.youtube.com/watch?v=Fgg7VPmfxVo&feature=youtu.be

Elv13 commented 7 years ago

Edit: ring-kde.zip

Elv13 commented 7 years ago

I updated the link above with the bleeding edge version. The one from Friday had a little crash once in a while. The new package isn't perfect, but at least it doesn't have that crash

Elv13 commented 7 years ago

ring-kde.zip

UriHerrera commented 6 years ago

Hi @Elv13,

@star-buck asked me to help out with the GUI work. Here's some of the mockups though there's more to make but should get you started on how to make it look native to Plasma like using native UI elements rather than making custom ones.

Account setup # 1:

Account setup # 2:

Account setup # 3:

Ring window # 1:

Elv13 commented 6 years ago

Thanks a lot for this. They look very nice. A few thing that probably will need to change:

make it look native to Plasma like using native UI elements rather than making custom ones.

Those are not custom ones. Those part the default QML Controls 2.0 theme on the current Plasma release. QML QtQuick Controls 2.0 doesn't support Breeze yet, it is why it looks different. All applications that use Controls 2.0+ are affected by this and look as everything looks above. Note that there is work being done fixing this by other developer such as Sho and notmart[1], but it isn't ready, yet.

Therefor there is nothing I can do beside writing custom widgets to make them look like the mockups. Unfortunately, QtQuick controls 1.0 and 2.0 are incompatible technologies and 1.x has no future and will be considered deprecated in Qt6. Ring-KDE 3.0 will have to use the "universal" default qqc2 style as shown above. The problem will solve itself once the QPA sets the new "plasma compatible" qqc2 theme to be the new default.

[1] https://cgit.kde.org/qqc2-desktop-style.git/

UriHerrera commented 6 years ago

Ah ok, we're working on a Kirigami app. I'll update them.

star-buck commented 6 years ago

How about we name it ring-qt? "Welcome to Ring-Qt, a frontend for the Ring Network."

Also, are we really working on a kirigami app? Lets streamline the currently used UI first instead of rewriting it yet again. The sidebar should be used for the tabs therefore, but the most important mockups would be the content inside the tabs while we keep the basic structure layout outside of the tabs content for now.

Elv13 commented 6 years ago

How about we name it ring-qt?

First of all, renaming an app is complex and require some extra work to make an automatic config porting system, breaks the namespace, dbus paths and confuse users. So this is not to be taken lightly. But most of all, it would be even worst than Ring-KDE. Both the Gnome, Windows and macOS Ring clients uses Qt. They are built on top of sflphone-kde (renamed ring-lrc) just as ring-kde is. The windows client also uses a Qt gui, but its mostly a dead end since the code is one giant ball of a mess.

However renaming the app would probably make sense if you wish to encompass things like emails and other media in the timeline. But that name should probably not use "Ring" in it since that would be a major deviation to what other Ring client do and would confuse users. It should also not use Qt or KDE in the name since such branding piggybacking only make sense for technical people and you repeatedly said you want a boarder audience.

If you don't want to change the name away from Ring, then I would advice not changing it at all. It's more trouble than it's worth (been there, done that).

Also, are we really working on a kirigami app?

Yes and no. It's currently a QML app without a real "identity". As you wished (and wisely so), all the work so far has been on features rather than design. As of now it's quite wireframe-ish and ugly, so it needs a design.

It doesn't need a "rewrite" to look like Kirigami, just a couple days worth of changes. However that's your decision and I am fine either way. So far I simply ignored the choice. If Marco work on the theme come to fruition, it will look like a classic KDE desktop application. Using qqc2 was a necessary decision. If I had not, the Plasma mobile version would not have been possible. It is also what Qt recommend to use, even if it isn't very mature and well integrated yet.

The sidebar should be used for the tabs therefore, but the most important mockups would be the content inside the tabs while we keep the basic structure layout outside of the tabs content for now.

Roger that.

Shall I implement the wizard changes or do you prefer the blue one? If I recall, all the mockup you asked me to draw inspiration from were blue (Skype and the Ring-android wizard).

UriHerrera commented 6 years ago

Ok so, from a technical perspective the UI can look however we want? @Elv13

Elv13 commented 6 years ago

Well well well, what a timing!:

http://jriddell.org/2017/09/06/qqc2-desktop-style-beta-release/

I will try it once I get a stable Internet access again. I am at the airport leaving for the Randa meeting, so I will be on IRC on and off for the last 40-somthing hours while I bounce around the world.

Ok so, from a technical perspective the UI can look however we want? @Elv13

I can say what's possible, but @star-buck says what has to be done. Here are the guidelines I got so far (in my own words). Until said otherwise, those are constraints on your design too:

For the next milestone (3.1.0 after the initial release):

(this have to be taken into account now)

Extra requirement (related to how Ring works):

@UriHerrera Also make sure you seen the current GUI, the screenshot above and ancient https://www.youtube.com/watch?v=AYba9uepFzs

What would be more pressing would be a more iterative approach to making the central canvas look nicer. I will provide you with updated screenshot with the Breeze theme ASAP, but for now just imagine that the widget will suddenly look normal once that missing KDE integration code is finally released.

UriHerrera commented 6 years ago

Question, other than the timeline button and the button below it (what does it do?), what else goes into the tabbar? or what else will go into the tabbar?.

Elv13 commented 6 years ago

The button below the timeline is the addressbook. There is also the history and the bookmark panes, but they are currently disabled as requested by @star-buck. If it was to become a Kirigami app, then there would also need to be a setting. The previous version also had a dialer mode for "real" phone calls, but it will need to be rewritten to QML. The dial pad is required when calling numbers with phone menu. The keyboard works too, but it was proven to be confusing during previous usability studies. Users find a dialpad widget more intuitive.

(Sent from my phone at the airport)

star-buck commented 6 years ago

Some thinking: History and Timeline should be redundant, at least conceptually. Bookmarks aka Favorites could be integrated into Contacts/Adressbook/People, where the starred ones can be at top or filtered?

star-buck commented 6 years ago

Lets concentrate on the two tabs we have though and see to visually refine them. To keep this from grwoing too long, I suggest using seperate issues for timeline and adressbook mockups.

UriHerrera commented 6 years ago

Alright so I redesigned the main window.

Timeline

I added a tabbar. It has 4 buttons: timeline, dialpad, contacts and settings and the user avatar at the top. It's not dark but it's using the colors from the Ring logo. It helps to have the branding integrated in a way in the software.

The timeline is divided in days and within each day the activity by contact ordered chronologically. The activity of each user is inside a message-like bubble, in it the recipient is shown the last message activity by the sender. Below that is the calls activity.

The color of the bubbles by default is gray. I think that the user could set a color for each contact to differentiate them (i.e. the background color and the text color).

Elv13 commented 6 years ago

Ah, now that starts to look its heading somewhere! Nice mockup!

Now, lets break this down a bit and improve some areas.

The information fields

Color coding

You chose to use random colors for the rectangle. I wonder if this is such a good idea and if it is, how should the color coding be based on. Most IRC clients use this for the last 30 years to make group chat usable. In that context, it works very well. Here, we don't have this problem. I wonder if it might be too flashy. I am a bit neutral about this. I am fine either way. I will let @star-buck decide.

If we choose to do this. What should be used to select the color palette? I believe starting with the Google Material color guidelines would be a good start. Letting the user choose a custom color (or pattern? or photo?) for a peer would also make sense.

Menus and toolbars

You removed both the menu and the toolbar. @star-buck asked for a new contact button in the toolbar. However, I tend to agree with you. They should be removed. At least by default.

Scrollbar

You opted for a persistent scrollbar. Are you sure about this? Don't you think an hover / autohide scrollbar wouldn't be a better option? There is little value in seeing how many peers you have in the peers timeline. You most likely wont ever have to use the scrollbar. The topmost items are usually enough. If there are not, then the search is the only sane way to see find them.

Dotted timeline

This looks beautiful. This is exactly what I had in mind, except your rendering is less ugly than mine.

So:

@star-buck:

(today, I am working on the appimage, tomorrow, I will work on fixing the accessibility problems as we have the required knowledgeable people available at Randa. I will start working on this soon after).

@UriHerrera:

UriHerrera commented 6 years ago

I'll update the mockup.

star-buck commented 6 years ago

@Elv13 :

Elv13 commented 6 years ago

Got it.

Also, the Kube/Sync team arrived at Randa today. We prototyped Ring-KDE email/contact integration this morning. I wont spend more time on this until you approve it, but so far so good. It works rather well actually. Note that the prototype is only the backend, I didn't implemented emails in the timeline yet, so there is nothing to see beside "umm, yes, they are successfully loaded". If I merge that branch, it will be a compile time optional dependency, just like Akonadi currently is.

star-buck commented 6 years ago

@Elv13 : sounds great! Who exactly is the kube/snyc team in Randa?

star-buck commented 6 years ago

lets do email integration after textchat and audio/videochat is done, like a major version 2.0

Elv13 commented 6 years ago

Who exactly is the kube/snyc team in Randa?

Christian Mollekopf and Micheal Bohlender

UriHerrera commented 6 years ago

My idea is that the user sets colors for their favorite contacts sort of like color tags in other programs like macOS finder or elementary Files. For example in the mockup the fields that use different colors are favorites, the fields that use #90a4ae #90a4ae are non-favorites this is also in the dots on the timeline itself.

In the other mockup I added the scrollbar to showcase how it would look like when there are more items in the timeline, if there aren't enough items in the timeline it shouldn't be visible as in this other mockup.

Elv13 commented 6 years ago

Ok, thanks. Once me and sgclark are done with the appimage I will release beta1 with the old UI. I will start to upgrade the GUI.

One last issue is that hardcoding grey color wont work. It has to follow the system (color) QPalette. Whatever color is there has to work in both light, dark and HiColor themes.

https://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKColorScheme.html http://doc.qt.io/qt-5/qpalette.html#ColorRole-enum

UriHerrera commented 6 years ago

One last issue is that hardcoding grey color wont work. It has to follow the system (color) QPalette. Whatever color is there has to work in both light, dark and HiColor themes.

https://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKColorScheme.html http://doc.qt.io/qt-5/qpalette.html#ColorRole-enum

So it can be any color from the color scheme that I can select in System Settings?

I used Inactive Titlebar Text for the fill and Inactive Text for the borders on the gray info. fields from the Breeze color scheme.

Elv13 commented 6 years ago

So it can be any color from the color scheme that I can select in System Settings?

The limitations for KDE applications are to avoid hardcoding colors as we have to support both alt color schemes and HiContrast for accessibility reasons (there's laws for this in various countries). Using random colors from the palette may or may not cause issues. In "the real world" we could try to use colors that looks like in both light and dark mode and have an alternate sets for High Contrast users. This should allow to ignore the problem.

"Modern" design HIG seem to avoid using the old palette concept that's in use since Windows 3.1. Google Material has well documented light and dark favored colors instead of forcing them from the toolkit. QtWidgets / Win32 / .NET / Cocoa still use the system palette concept.

So I am not against using custom colors, but I am against hardcoding the whole design. This voids our application guidelines and is a no go for a KDE app. If we can come up with a compromise that supports all 3 "common" type of look (light/dark/HighContrast), then it's fine. However, the QPalette should always be favored for common colors (all greys background, text and panel background).

UriHerrera commented 6 years ago

I'll add a mockup with the colors from the High Contrast color palette.

Update:

Here I used the colors from the High Contrast palette in Plasma.

UriHerrera commented 6 years ago

Or could be like this: Don't force the colors but just add a star to the favs. Much simpler.

star-buck commented 6 years ago

since the ground work has been laid, lets close this here and evaluate each main screen option in detail in seperate topics after alpha1 appimage gets shipped.