Ripper/Converter/Encoder window replacement

[sbooth]

I've been working on a replacement for the ripper/converter/encoder windows and I've come up with something that I think will work and be more user-friendly.

Here is a screenshot of what I have so far (a partly working mockup):


Basically, the idea is to have a file or track show up only once and the status line("Encoding to Apple Lossless" in the example above) and progress indicator change depending on what is happening. So for file conversion, the initial status would be "Converting", followed by "Encoding to xxx" for each output format that was selected. The timer indicates the time remaining for each phase.

The main drawback to this is when only one file is in the queue. While the current version of Max will encode a single file to multiple formats simultaneously, this new design will only encode a single file to a single format at a time. So, a bit of performance could be lost. I was unable to come up with a way around this- how does one indicate to the user that a file is being encoded to multiple (possibly dozens) of formats simultaneously while keeping things simple?

[krmathis]

/me like this one!
I think that one common ripper/converter/encoder window would be nice. Especially with the dynamic progress indicator which change depending on what is happening. Makes the UI cleaner and easier to understand.

I am willing to sacrifice the option to encode a single file to multiple formats simultaneously for a better UI. Especially with todays fast Mac´s.

[RonaldPR]

how does one indicate to the user that a file is being encoded to multiple (possibly dozens) of formats simultaneously while keeping things simple?

"Encoding to multiple formats" ?

[Steve]

That looks really nice. Very clean and simple. That said, here's a few thoughts and suggestions:

1. Add the number of steps to the converting/encoding text, something like: "Step 2 of 3 - Encoding to xxx"

2. You have stop buttons, but what about pause buttons? I'm not sure if they would be used or not.

3. Should "Stop" be changed to "Cancel"?

4. For multiple encodings of a single track, instead of my first suggestion you could expand the rows just enough for additional progress bar(s). Something like this:

====================================
Opera Singer
------ Encoding to Apple Lossless
------ Encoding to Ogg Vorbis
------ Encoding to MP3
====================================
Comfort Eagle
------ Encoding to Apple Lossless
------ Encoding to Ogg Vorbis
------ Encoding to MP3
====================================

I know that this kinda gets away from clean and simple but it's not too bad. Your call, of course.

[Fuga]

So, when my daddy said I was trying to have my cake and eat it, too, my mind would start spinning madly because I thought that of course I dd. WTF would bother having cake if they couldn't eat it?!

The number one advantage (still pending) of Max is, of course, secure ripping. But the multiple format thang is a glorious process. If you're going to have all that going on I am not sure you can have the ultimate simplicity being discussed.

I want the multiple processes. I want as much feedback as possible. If I can't eat the GUI "simplicity," so be it.

[sbooth]

The more I think about this (which has been a lot lately) I'm tending to reverse course and agree with Fuga on this one.

I think that, especially with the new dual and quad Macs, an advantage of Max is that it is able to process even a single file in a multithreaded way if you are encoding to more than one output format. The speed gains would hopefully be noticeable, but I don't have a multiprocessor/multicore machine so I can't say for sure.

I agree that the current window setup leaves something to be desired, but for the life of me I can't come up with one that looks good and gives the user the info they need, while preserving the way Max currently works. It is a possibility to combine the encoder/converter/ripper windows into one, which might be a slight improvement.

I will try and find some OS X batch-processing software for other ideas.

[l008com]

iTunes 6 + Photoshop = The solution to this problem. Wanting Max to have a "1 Window" interface doesn't mean one window for everything, it means one window per.... function. In other words, one window for cd ripping/encoding, and one window for file converting. Here is my mock up. Its not a .nib, its all photoshop.



See each CD you insert shows up in a similar way as it does in iTunes. Only as the songs get ripped, they move over to the encoder on the right. Unlike the current Max setup that keeps a million CD windows open at a time, the left CD column of my UI only shows actual physical CDs in your computer. When they are done being ripped, and all the songs are added to the encoder, the CD ejects and disappears off the on screen list (possibly with a neat apple like ripple effect ).

I figure that based on the MB in the encoder queue, you should be able to get a fairly accurate ETA for processing the whole queue. It should be going backwards as you added more and more CDs but once the ripping of CDs stopped, the encoder could count down nicely.

Another thing I thought of that isn't directly related just to my UI mockup, is that when there is a choice of tag info from the tag database, theres no reason why you can't start ripping anyway, since all the AIFFs are stored with coded names anyway, the tag data could just be applied once the encoding started.

The converter really only needs a one column windows. A list that you can drag files directly too. Then that list IS the encoder window, that Max goes through and encodes, and takes files out of the list once they are done encoding.

And what would also be great to integrate is the crash recovery techniques I put in a thread earlier today.

Also I started to get tired of photoshoping and I left out the indicator(s) of hard drive space in the Max window, that is a MUST. And I just put two buttons at the top but of course as many as you have just go across the top there. Both the ripper and the encoder would need to be able to scroll. I forgot to add teh scroll bar to the ripper column and didn't feel like adding it when i noticed. Also the ETA times are all screwy, again I just didn't feel like trying to come up with real looking data.

[l008com]

Little more:
CDDB doubles would still come off this main window in sheets asking you to pick. Ideally the sheet would be bigger than it is now, to show more data to help make your choice. Also these sheets should stop or slow down ripping and encoding processes already in progress. And when there were multiple CDs that need you to pick tag data, best I can figure, is just rapid fire the sheets.... as soon as you pick the tag data on the current sheet and it slides up, slide the next one down and pick THAT ones data. And repeat until there are no more choices to be made. Another interesting feature would be to be able to pause and resume encoding in the encoding queue. Rippers would still be adding to the queue, but you could stop the actual encoding if you had, say, something else you needed to do that was CPU intensive and important.... Just a thought.

[Addition]
One of the problems mentioned earlier in this thread was how to manage ripping songs to multiple formats. They way I would handle this is when a song is done ripping, add it to the decoder once for each format you have enabled to output too. I didn't put in a format column in the encoder but its just a mockup. Then multiple format encoders would be the same as regular encoding.

[Also]
Just in case its not clear, what you see in the Ripper column is whatever CD you are currently clicked on in the CD column. So you're not seeing ALL the CD tracks that are being ripped, you are see each CD as it's own list. Similar to the way iTunes shows CDs. And when you clicked off the CDs, and none were selected, the Ripper list would be blank. So the CD and Ripper columns are tightly tied together. Unlike the Encoder column, which is kind of its own piece, its contents don't change by clicking on anything, it would always show all the songs queued up to be encoded.

[l008com]

So Mr Booth, any thoughts on the mockup? And all of my recent suggestions/requests in general?