[BIG ONE] Changing bliss to a task queue work flow style.
I believe this idea will fundamentally improve the usability of bliss. I purchased bliss in hope it would save me huge amount of time w/ managing a music collection of (5000+ albums and growing...) However, I found bliss saved me some time, but not that much!
What I realize is while bliss' idea and its features are great, the productivity issue is in the UI workflow design.
Bliss automatically scans library in the background, but most fix actions are designed to be done interactive(in real time). I found I choose the non-compliant album and click on fix, and then WAIT for bliss to complete the action....before I can move on to the next album.
My time is mostly wasted waiting for bliss to complete an action. (frankly, bliss is not that fast in performing a lot of actions)... Often this fix action is also happen simultaneously with bliss scanning the library in the background, which making it even slower.
Also for an attempt to automate some of the feature to avoid excessive repetitive steps. Automatic option features are introduce for some of the fixes. The problems with automatic fix is not sure if every fix to be performed is done correctly. I always afraid bliss making a wrong decision on a special case, or the online database information is incorrect. that happens! Some people asked to have a log of what action bliss has taken, i think that to some extend is reflecting the same problem.
The idea is allow Bliss to support the concept of fix queue. Basically an asynchronous queue detach users action and actual job. Allow user extremely fast to browse and making decisions. Then bliss can take its time to execute (sequentially or in parallel depends on action type) completes and logs action. If further result is needed (ie. pick a albrum art). It can remember the result, and have user come back to make a quick selection, requeue the album updating task as another task to be performed in the background.)
So,
Scan library for fixes -> present fixes -> user selection -> actual fix --> [loop to present fixes .....]
are much better work flow then current real time fix.
I hope to save all bliss user a significant amount of time and making bliss a much more useful tools for the world :)
James
shared this idea
-
Hey Walt. In general, when you refer to responsiveness, do you mean responsiveness in the UI as-is (e.g. click a button, takes an age to respond), or the fact that the flow and layout of the UI as-is is causing the responsiveness (it takes too many clicks to do something)?
>>> Walt >>>
If I approve a suggested change, like a genre update, does bliss immediately go off and work on storing that change and rescanning that album? Or does it file that instruction away for processing in the background and continue to pay attention to me?
>>>It passes it to a queue of work being done, and immediately returns. In the meantime, the album should be marked "in progress" which should show the spinner icon. Yeah, you can do stuff while that's working. More progress reports may be helpful here... there's the delay in case the queue is full (this is common when a wider scan is ongoing) plus some changes can take a while to complete (particularly if you are connected to your music files via wireless, for instance). Are you seeing long delays? I've long wondered about treating user manual actions as higher priority.
>>> Walt >>>
I don't know if James's idea is the perfect solution, but I definitely think he's onto something here. Decoupling the performing of the tasks (by bliss) from the foreground UI would make the user's workflow less dependent upon the time it takes to apply a change, rescan the album, and update the page.
>>>This isn't my reading of what James is saying, but I may be wrong. I thought James was suggesting moving from an "object oriented" view of tagged concepts (albums, artists etc) to a "process [or action] oriented" view ("Fill in missing artwork", "Fix music files") which takes you through the workflow of fixing those things. But as I say, I may be wrong.
-
Walt
commented
My biggest issue with this otherwise excellent software is UI responsiveness, and this user's suggestion really hit the nail on the head for me. I know this thread is old, but I'd still like to chime in. Dan, in response to your question, I think the distinction lies in WHEN the work is performed by bliss. If I approve a suggested change, like a genre update, does bliss immediately go off and work on storing that change and rescanning that album? Or does it file that instruction away for processing in the background and continue to pay attention to me? I might also want to choose new album art, for instance. If I do, I have to wait 30 seconds or more, or I can go off and work on some other album and try to remember the other change I wanted to make, even though this album may no longer show up in the non-compliant queue after the genre fix.
I don't know if James's idea is the perfect solution, but I definitely think he's onto something here. Decoupling the performing of the tasks (by bliss) from the foreground UI would make the user's workflow less dependent upon the time it takes to apply a change, rescan the album, and update the page.
Just to keep things in perspective, I want to mention that bliss is already better than anything I'd hoped for just a few weeks ago. You're doing some great work here, and I'm telling everyone I know about it!
-
Jim
commented
The inbox does not containe all the items that are not compliant other then that I do like using the in box
-
This is basically what the Inbox is an attempt to do. How do you think that could be improved to satisfy these requirements? I suppose it doesn't show already-fixed items for starters. The activity view shows that, although with too much other info, possibly.
