Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UI overhaul #18

Open
jcgruenhage opened this issue Mar 11, 2017 · 2 comments
Open

UI overhaul #18

jcgruenhage opened this issue Mar 11, 2017 · 2 comments
Milestone

Comments

@jcgruenhage
Copy link
Collaborator

The UI looks kind of messy, and makes things like #9 not really intuitive. I thought of something like a card based list of items, that includes everything (artists/albums/playlists) that can be then filtered down.
The cards could then be expanded to show a track list, clicking on a song selects it and so on.

This would fix the horrendous layout that results from setting your display size to smallest on nougat, where it currently shows the two pane UI, squashing together the album title so much that album titles starting with american won't even fit more than that one word (see this).

The main problem is, that I have no experience yet with card based layouts, so that may take some time, during which I won't be able to work on any of the other (few) things that are still in the pipe. Thankfully, everything seems to work rather good at the moment anyway, so not working on other stuff is not really a problem ^^

@ghost
Copy link

ghost commented Mar 12, 2017

There is a nice library for card based layouts. https://github.com/gabrielemariotti/cardslib

Perhaps try out come ideas using online UI mock-up tools, there are a few that support android widgets, i wonder if they do card layouts too??

I think there will be some users that want to export from the UI, single or multiple items (items being albums, artists, individual tracks or playlist of tracks), there will users that want to auto-export everything or just watched/pinned items, we should cater for all these use cases.

Some form of pinning of items, the FAB would then export everything pinned. Auto export could then have a setting for exporting everything downloaded, or just everything pinned.

As for exporting non-downloaded stuff, incase it ever gets downloaded, that to me sounds like an edge use case that is likely to confuse people. The workflow should always be download first, in my opinion.

@jcgruenhage
Copy link
Collaborator Author

jcgruenhage commented Mar 12, 2017

Well, I don't see the difference between auto export handling everything pinned and marking non-downloaded stuff for export, should they ever be downloaded :P

That being said, I would like to avoid adding a new 3rd party library for that, but luckily google also provides a support library ('com.android.support:cardview-v7:25.2.0') for that. I've already done some experimenting on that:
screenshot from 2017-03-12 12-38-38

Expanding it, to show the songs is somewhat harder though :D

We might also want to include some more information or buttons on that card, since it looks rather empty at the moment.

Edit:
I used a constraint layout inside that card view, which might be a problem, since it is currently shipped from the non-free Google repository. That means that we won't be able to let F-Droid build the app with that included. I guess Google will push the library to it's free repository, once it is released, but who knows? Maybe I should switch that back to using a relative layout.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant