Feature #1472

Improve app usability through display of metadata in graphical layouts

Added by megabitdragon about 7 years ago. Updated almost 7 years ago.

Target version:
Start date:
Due date:
% Done:



For larger layouts, I suggest using a grid rather than list view for better using the layout. I will add more things here but I have to think them through.


Feature #1530: Display only the movies and folders for shares with "movies" tagFeedbackmegabitdragon


#1 Updated by megabitdragon about 7 years ago

  • Priority changed from Normal to High

#2 Updated by ming about 7 years ago

  • Status changed from New to Feedback
  • Assignee changed from ming to megabitdragon

#3 Updated by megabitdragon about 7 years ago

Cannot test yet. No tablet in hand.

#4 Updated by cpg about 7 years ago

we got the mockup of the movies view from the designer. this is not pixel accurate, but it gives an idea of what the movies share view should look like:

in order to get the metadata for a given file, please see #1476

#5 Updated by ming about 7 years ago

  • Assignee changed from megabitdragon to cpg

Bodain initially suggested to use grids to fill the empty space on tablets. Does it mean this idea should be abandoned and there should be lists everywhere except shares supported for metadata?

#6 Updated by cpg about 7 years ago

After seeing the grid in action instead of lists, I feel the grid does not provide much value when we do not have metadata, because the icons do not provide much more info by being bigger, yet all the names of files, like docs or music, or movies are all cut out short.

we're talking lists vs plain non-metadata grids

in this case and most others i have tried, the fact that the icons are aligned and the names are all aligned in a line and not cut off, the usability of the lists is better.

now, for shares that we expect to have metadata for files, i would hope that the grid will be better as witness by virtually all media apps out there that use artwork and such, from apple tv to plex, xbmc, to xfinity, to many many others. we may have to work on the grid proportions, etc. to see how things show in practice, and we will also have to work on how to show the titles in a way that it's user friendly, however, it will be much much better.

When to show metadata

in regards to when to show grids, since at the moment we can only really support metadata for two things, movies and tv programs (we will deal with music later), the algorithm is:

  • share tags have priorities - the first "match" for either movie or tv wins and that share is considered to have movies or tv episodes (for metadata purposes)
  • a tag that matches ".*movie.*" (in other words, a substring) is a match for movies and shows the grid for the share and the metadata is displayed. the hint for the api call becomes "movie" (note, we look for the substring movie, not movies)
  • if there is no match for movies, the app checks the tag for a match on tv episodes
  • a tag that matches ".*tv.*" (in other words, a substring) is a match for tv episodes and show grid and the metadata is displayed
  • the app does not display metadata on folders for now (this may change later)

example: a share with three tags ["kid's", "movies", "tv"] will match for movies. one with ["tv", "movies", "kids"] will match for and show tv episodes

#7 Updated by cpg about 7 years ago

  • Subject changed from Improve tablet layout to Improve app usability through display of metadata in graphical layouts

i am changing the title to reflect that this is more about general usability and presentation than tablets.

as to what to do for phones .. i would try to do the same thing as tablets first (e.g. with less columns per row)

the idea is to make rows of about these many movies per row: int(horizontal_resolution/360)

  • for 1920px (nexus 7 horizontal) => 5 per row
  • for 1080px (nexus 5 vertical) => 3 per row
  • for 1200px (nexus 7 vertical) => 3 per row

for best performance, the images should be lazy loaded.
there are many examples of web apps and mobile apps where the images in the list are not loaded until the row is actually shown to the user.

so if people have 200 movies, the images only show after the user scrolls up and they are visible. and the first render will be much faster than loading all 200 metadata pieces.

after the first fetch/display, the images should be in the cache for a while, so rendering will be faster even when the user moves quickly.

#8 Updated by ming almost 7 years ago

Images loading from the implementation side concerns me less than API requests itself. For now there is a files list request + a request for each file, i. e. N + 1 HTTP requests for N files. For 10+ files it is already not very efficient for battery life. Plus potentially N requests for artwork. There is a way to cancel image downloading automatically (Picasso library does it), but there is no way to properly cancel HTTP API requests. Any ideas how it is possible optimize this issue? I thought about inlining metadata into files response when using some query parameter.

#9 Updated by cpg almost 7 years ago

  • Assignee changed from cpg to ming

let's walk before we run please.

in any case, i believe this will not be a problem in the api side because:

1) remotely we turned on spdy a few days ago and okhttp uses it1, only one tcp connection for all http calls to the origin server
2) locally it's extremely fast. we will switch to spdy when local later
3) there is a cache in the origin server so the response is immediate if the data was requested before

so, if the artwork (which a single file is 10 to 100 times larger than the metadta) can be done efficiently

1 here is how to tell in the log:

org.amahi.anywhere D/API? OkHttp-Selected-Protocol: spdy/3.1

Also available in: Atom