UI Design Discussion

[Guy-kun]

I've been straining over thinking of a proper UI for in-app but the one big hurdle is having no central content for what is in effect a media player.

What would be really great is to have a bigger minimum size for all DJ images, the current size is just too small. Up to 1024x1024 would allow a really great 'album-art' style central image with payer controls and metadata next to it, having the queue and recent accessible through a gesture/page.

Would this have bandwidth implications and be unrealistic? If so, a second hi-res image field would be possible through the api to at least stop browser clients loading this unnecessarily

edit by Autumn - renamed issue

[Autumn]

I don't think the bandwidth would be a major problem. The DJ image is only downloaded once per run until it changes, and we should be able to do some sort of caching.

Do you have any design wireframes we can pore over? Discussing the UI would probably be the best way to decide on one.

[Guy-kun]

I'll throw one together, sure

[Guy-kun]

I love the Google Music UI, and familiar things are good, right? right???!?!?! So I've worked off that basically The idea is that the main player interface such as this is pretty simple/eye-pleasing to be left as a decoration (who actually goes outside and uses their phone?) and other features lie off sub-menus/other sub-interfaces

Having the context menu bottom left may be weird, but having the queue/recent come out from the side in a yet undesigned UI would work best from top right, so I've positioned it there.

A 1024x1024 image should suffice in almost all cases and can be stretched to be lenient.

DJ Info would be found pressing the top-left icon

[Autumn]

I like it. I'm a fan of the Google Music UI as well.

Would you have the queue/last played information in the right side bar, with the DJ information?

For "other parts" of the app (favourites, chat?), I'm thinking a navigation drawer on the left.

For searching and requesting, I think a search widget in the Action Bar would fit in nicely in this design, rather than in the aforementioned nav drawer.

As for the DJ art, would an option to serve multiple resolutions be out of the question? A lot of users screens (granted, none of the seven installs right now have a screen >720p) could possibly be high resolution, and a 2x upscale on a device of that type would look...unsatisfying, I think.

[Guy-kun]

I'm not sure what you mean by right side bar but the idea was of either a modal scrollable popup with queue/last played or a drawer to the right. This would be overkill with a drawer for other parts of the app though. The bottom left context menu thinking about it should keep only current-track related options such as favourite if this comes.

Maybe we can cheat a navigation drawer and use it as both navigation and a collapsible sub-category just for showing the queue/recent.

A search icon on the top 'action bar' would be easily doable, plenty of space on there

Honestly speaking, most devices with > 1280 width are likely to be compact/high-density devices, a 1024px image enlarged by x1.2 won't be bad I think, you use tablets at a further distance anyway. Might be overkill to serve anything over 1024 and scaling down in-client isn't an issue as a one-off

[ameliaikeda]

We'll force a resize on the main site and provide 1024x1024 DJ images, Caching/lazy loading would be a good idea here, too

[Guy-kun]

Implemented on the player-ui branch with a few adjustments to the design and main DJ image is static until 1024px images are provided R-a-dio/Android-app@4a9111f67184cdbad251e45bee08af1c3fa2c0e8

[Guy-kun]

UI looks as such: Bottom left context menu can contain anything track-related such as favourites or more buttons can be added to the bottom bar.

Still undecided on the main method of navigation to other parts of the app.

[Bevinsky]

I'd just like to point out @HirotoKun, while I can see large image sizes like that being great to have, it might not be possible in every case due to cropping/original image size. DJ images of that size might be hard to procure.

[Guy-kun]

Re-thinking, that's right. Only having one 1024x1024 image would mean dj images would be small and look like a down-sized wallpaper most of the time (unless a really high-res source is used). Take as an example a face. A 1024px face would be hard to find, and a full-body shot may end up too small when used scaled-down.

A smaller size as currently exists to be used as a 'avatar' and a 1024px version to use where needed would be best.

[ameliaikeda]

@Bevinsky 1024x1024 would be really hard to actually procure properly for a high-res shot yes. But we can still try.

[ameliaikeda]

@Guy-kun that actually looks sexy. I like. Also, since we have DJ Themes on the website, maybe change images in the center per-DJ? And you could probably also make the progress bar change colour (we talked about this in the staff channel on IRC). We'll provide the RGB values in the main /api.php with the key "dj_color"

[Guy-kun]

The central image changing is exactly what was planned. Rgb value for the progress bar sounds good too. It can be used for other trivial stuff such as selected glow on buttons. On 2 Jul 2013 09:08, "David Collinson" notifications@github.com wrote:

@Guy-kun https://github.com/Guy-kun that actually looks sexy. I like. Also, since we have DJ Themes on the website, maybe change images in the center per-DJ? And you could probably also make the progress bar change colour (we talked about this in the staff channel on IRC). We'll provide the RGB values in the main /api.php with the key "dj_color"

— Reply to this email directly or view it on GitHubhttps://github.com/R-a-dio/Android-app/issues/20#issuecomment-20332241 .

[ameliaikeda]

@Guy-kun @Autumn @resttime Just made a Change that you guys will love; I made the JSON api prettyprint. Also that RGB value is "djcolor":

{
    "online": 1,
    "np": "marasy - Senbonzakura",
    "list": "141",
    "kbps": 192,
    "start": 1372772704,
    "end": 1372772996,
    "cur": 1372772724,
    "dj": "Hanyuu-sama",
    "djimg": "\/res\/img\/dj\/i9vacc.png",
    "djtext": "The AFK streamer, still in development while being in use. Don't blame her when something goes wrong! (Blame Vin or Wessie)",
    "djcolor": "51 155 185", // R G B
    "thread": 0,
    "lp": [
        [
            "1372772704",
            "Narumi Yasuda - Kaze no Tani no Nausicaa",
            0
        ],
        // omitting the rest
    ],
    "queue": [
        [
            "1372772995",
            "Yasunori Mitsuda \/ Natsumi Kameoka - Flight - Orchestra Version -",
            "1"
        ],
        // omitting the rest
    ]
}

[Autumn]

Would it be possible to separate the np attribute into npartist and nptitle? I've noticed that a few songs have multiple hyphens, where it's ambiguous (to the code) which grouping to respect (two hypens in song or artist). Splitting it into multiple attributes would make the code more resilient, and end an annoying UI inconsistency, where a parse failure shows up as "- -".

EDIT: I see you guys discussed this in the channel.

[Guy-kun]

This would be wise. As a temporary fix, the player-ui branch already includes a fix that presumes the first hyphen is the artist separator and all subsequent belong to the song name. On 3 Jul 2013 00:07, "Andrew Coleman" notifications@github.com wrote:

Would it be possible to separate the np attribute into npartist and nptitle? I've noticed that a few songs have multiple hyphens, where it's ambiguous (to the code) which grouping to respect (two hypens in song or artist). Splitting it into multiple attributes would make the code more resilient, and end an annoying UI inconsistency, where a parse failure shows up as "- -".

— Reply to this email directly or view it on GitHubhttps://github.com/R-a-dio/Android-app/issues/20#issuecomment-20385366 .

[ameliaikeda]

it's incredibly easy to separate this. we'll do it as extra in the json for now, but we will be migrating to a new api soon - we just need to code the backend (tip: it'll probably be a REST frontend with a python api backend)

As with all things we say we're going to do, expect it in 6 to 8 weeks.

[Bevinsky]

The problem with separating the artist and title is the same as the problem in the app right now; there's no way of knowing if the split is correct or not. That will probably apply to the new API as well.

[ameliaikeda]

@Bevinsky but we store them in different fields, and can expose them at will.

+---------------+------------------+------+-----+---------------------+----------------+
| Field         | Type             | Null | Key | Default             | Extra          |
+---------------+------------------+------+-----+---------------------+----------------+
| id            | int(14) unsigned | NO   | PRI | NULL                | auto_increment |
| artist        | varchar(500)     | NO   |     | NULL                |                |
| track         | varchar(200)     | NO   |     | NULL                |                |
| album         | varchar(200)     | NO   |     | NULL                |                |
| path          | text             | NO   |     | NULL                |                |
| tags          | text             | NO   | MUL | NULL                |                |
| priority      | int(10)          | NO   |     | 0                   |                |
| lastplayed    | timestamp        | NO   |     | 0000-00-00 00:00:00 |                |
| lastrequested | timestamp        | NO   |     | 0000-00-00 00:00:00 |                |
| usable        | int(1)           | NO   |     | 0                   |                |
| accepter      | varchar(200)     | NO   |     |                     |                |
| lasteditor    | varchar(200)     | NO   |     |                     |                |
| hash          | varchar(40)      | YES  | UNI | NULL                |                |
| requestcount  | int(10)          | NO   |     | 0                   |                |
| need_reupload | int(1)           | NO   |     | 0                   |                |
+---------------+------------------+------+-----+---------------------+----------------+

Hence, we can separate those that are Hanyuu songs. For others, we just guestimate.

[Bevinsky]

@HirotoKun Yeah, for songs in Hanyuu's database it's not a problem, but we don't serve NP data from there in the first place. Everything is passed through the esong table which doesn't store them separately.

[Guy-kun]

Where da 1024px dj images at