Daftcat-

Awesome. I love those.

What do you think of this as a new splash screen?

http://www.eds.org/~straycat/mlbsplash.jpg

This is based on an older version of our VERSION text but we can change that.

Please keep in mind the splash screen is only there to serve as a buffer between the time you start the application and when the listings load. There are no additional sleep commands in the splash code. So under normal network conditions, the amount of time this screen would be displayed would be relatively short (unlike Adobe Photoshop or Gimp, for example.)

What do you think?

a) Keep it simple. I like the splash the way it is.
b) That rocks. Let's go with it.
c) I'm indifferent.

Pulled it down on another machine and it all worked fine. May just have been timing. I'll go back and try the original.

I would actually go for (a). Not necessarily because of personal preference (I'm pretty indifferent, as far as that goes), but because MLB is one of those entities that is *very* touchy about its brand property. And this logo possibly moreso than anything else, since it signifies their imprimatur (a real, licensed cap vs. a knockoff). Frankly, we probably shouldn't even be using 'mlb' in the program name, but I don't think that's a big deal. This, though, might actually lead to a cease and desist if we released with it.

Good call.

Poll closed.

How about "b". I like it plus I'd like to see if they are petty enough to whine about it. I suspect they may be, however. I wish I wasn't addicted to MLB, I gag every time I end up giving them any money.

I really like the addition of the top play listings, it's great stuff.

I'm with jkr on the logo, there's no sense in doing anything to upset major league baseball. That's not to say you shouldn't add some sort of splash screen, just that it shouldn't look like a copyrighted image.

Is there any way to let us make our own ASCII splash screen (and maybe put a variable somewhere to let it know where to put the version info)? That way if people wanted, they could make the MLB or their team's logo in ASCII art, but it wouldn't be officially released with it so it shouldn't attract the hounds

Ah, now this is the beauty of open source. This sounds like a great opportunity for you to look at our splash screen code (which is all of about four lines) and decide if you want to implement your own custom splash screen (which would bloat it up to about six or eight lines.)

The biggest problem I see with implementing a user-defined splash screen is replacing whatever user-defined tag with the version string. I guess if the user wants to go through all the trouble of formatting an ascii graphic that doesn't look like a$$ when cooked through curses, then it should be up to them to also figure out where to put the version string in, how long the version string will be, and go through all the iterations of poorly formatted splash screen until they get it right.

All in all, this doesn't really sound like a feature I want to implement--a very low bang to buck ratio. Try bribing me with tickets and maybe I'll reconsider. ;-) What's your local team?

I tried a knock-off of the MLB logo with a silhouetted Tux, the penguin, but it was virtually unrecognizable as a penguin and wasn't fat enough to accommodate a version string. Who wants a skinny penguin?!

I'm looking at the alarm clock feature and then I'm calling it done for this release. I probably should implement meta-refresh for "Estimated delay" pages but it might be more annoying to wait for our app to retry under network congestion conditions. Perhaps I'll just write a "mlb.com congestion" error message and call it a day.

I'd like to get a working version of mlbscores (which is behaving very badly right now) into the next release.

Question:

Is it more intuitive to use 'L' (or lowercase 'l' too) to return to listings from Top Plays or would you rather use 'q' to quit out of the Top Plays screen?

My feeling is that 'q' should work universally to quit the application no matter what screen you're in and thus, 'l' or 's' (when scores is implemented and integrated) would indicate which screen you want to go to next.

Personally, I think "t" should jump to "today."

I propose a menu-based system where you go to the day and game you want and press "m". This would bring up a menu for that game where you could select:

Audio
Top Plays
Game Notes
Box Score
Record (if implemented)

"Esc" would be the universal "Back" function. It also makes it easier to add functions as menu items rather then assign them hotkeys to remember.

Ahh, I hadn't looked at the code, and just thought you were feeding it in there in plain text, so thought you could just pull the text from a file. I may add my own in there, but then I would have to re-do the changes everytime I pull down new versions from svn right? (this is my first time using svn)

I'm from St. Louis, so I'm a Cardinals fan, although I don't live there anymore. I'm in Columbus, OH now, so I don't really have a 'local' team. I'm right in between Cincinnati, Cleveland, and Pittsburgh.

I hate menus because they are clutter magnets. What starts with a "Game" menu, turns into a "Preferences" menu, a "View", a "Help", etc. The other problem with menus is that we'd probably have to draw the menu differently based on the screen we're in, so it becomes another object to manage and more state to keep track of.

I hate "Back" buttons too. I like progress. If I want to start at listings, check the scores, see the line scores, the box scores, and then the highlight video of Alex Gordon's HR, I want to say, "take me to it" rather than retracing my steps until I reach a junction point again. I'm a big fan of hot keys because it's instant gratification (no hoops to jump through or menu options to look for.) From a code perspective, "back" functionality becomes a pain because then I have to keep a history of which screens you visited.

I can sympathize with having too many, though. Hotkeys is both a strength of mplayer and a point of contention. I find myself going to the docs or the man page frequently to figure out which hotkey does what I want. I think <enter> in jump prompt makes it easy enough to jump to today without wasting another hotkey on it. At least 'h' for help should work in every screen. ;-)

A compromise I could think of is to put hotkey hints at the bottom of the screen above the status bar like pine and nano (except without having to use the Ctrl-key to get anything done. ;-)

Another thing I'm talking to jkr about is supporting a core set of actions for each screen and implementing each screen as its own class. The screen would have to implement each core action (or print a "not supported" message.) The user experience would be a common set of methods like up/down/left/right/enter/jump/audio and selecting which screen they want to go to. This is similar to the web experience where you select your screen (scoreboard, standings, players, teams, etc) and your actions (play video, select date, give me more details.)

I'll look at the hotkey hint bar and see if it adds more value than clutter.

Maybe I wasn't clear. I said "back" when I meant "up," I suppose. Think of it this way:

You navigate to the game that interests you (the object) and then you press one button that gives you a list of things you can do with that object. "Escape" just gets you out of that. It would do the same thing the "L" key does when you're in the "Top Plays" menu.

You already use menus, I'm just suggesting using one more to make the program's features transparent. Not only does it eliminate the needs to remember (or use a legend) all the hotkeys, it allows users to see new features after an upgrade without having to dig through documentation or read changelogs.

Suppose MLBAM reinstates Condensed Games and you add support for it. If you have an "action" menu, users can clearly see that "Condensed Game" is now something they can do with their chosen game. Otherwise, they just have to know that pressing "C" will accomplish this.

I'm not proposing a menu system like desktop applications have (File, Edit, View, etc.) but more of a navigational vehicle, akin to MythTV, though simpler.