Hi HN,<p>I'm exploring a UI idea, and I'm posting it here in search of some critique and feedback. I'll jot down a few stringths and weaknesses I'm thinking of so far. I'd love your input.<p>Here's the youtube demo link:
<a href="https://www.youtube.com/watch?v=YkXgcS6kT4U&feature=youtu.be" rel="nofollow">https://www.youtube.com/watch?v=YkXgcS6kT4U&feature=youtu.be</a><p>Here's the github repo:
<a href="https://github.com/mikemajzoub/ResponsiveGrow" rel="nofollow">https://github.com/mikemajzoub/ResponsiveGrow</a><p>Abstract Use Case:
Allow the user fast access to any data containing a uniquely identifiable graphical ID (badge, emoji, profile picture, color in palette, etc.). As user moves around grid, views details of current node in top part of screen.<p>Strengths:
1. A common solution to represent such sets if data is generally a scrolling UITableView (iOS) or ListView (Android). This is inefficient because it requires time and energy for the user to discover off-screen options.
2. Its simplicity lends it to be memorable and learnable.<p>Weaknesses:
1. As the size of the set grows, the node's graphical IDs decrease in size, detail, and as an extension, recognizability. In the demo video, that's a 15x15 grid, which I felt was really pushing the set size limits... but then again on a UITableView or ListView, representing 225 elements would be a nightmare too. I'm a little conflicted on this point - would love some feedback here.<p>2. I'm currently losing screen space at the bottom and edges of the screen so that the margin can accomodate for the growing of the squares near it. One potential solution is removing the margin entirely, and then shifting the entire grid in the opposite direction of the currently selected area, because if the user is in the lower left corner, she probably doesn't care if the upper right corner slides off-screen momentarily, does she? Do you think this is a viable option?<p>3. I'm still conflicted on how to allow the user to select the data. "On release" seems like a potential option, but this means the user will have to drag all the way off the grid if she chooses not to select anything. Perhaps this challenge presents an argument for keeping the margins, so that at any moment, the user is within screenWidth/2 distance from the "do not select" area. Another potential solution would be to allow for a hole in the middle of the grid, which means that the user would always be within screenWidth/4 from the "do not select" area, but this cuts into the amount of data that can be represented on screen, so I am not in love with it. I welcome (and beg for) any ideas here...<p>Thanks for your thoughts and feedback - I'm still very much in the early stages of this idea, but I think it has some interesting potential and wish to keep exploring and evolving it.<p>In peace,
Mike