How do you prefer TNGTony's DISH channel chart? (UPDATED)

Would be nice to have all of them - as i like 'em all...

(and on fast internet connection - it does NOT make any difference to me.. to wait few seconds extra or less .. one way or another)

But if impossible to have ALL the charts (understandably so) - i voted "Leave the chart the way it was and stop messing with it!" , lol

Cuz i actually do NOT mind the way it is now

P.S.

Actually "with links to local maps only" .. but keeping it the same as now otherwise is pretty good also i guess

oldave, I can tell you from experience that generating anything on that scale on the fly from a database (using typical technology anyway) will take a lot more time to transmit and enough server cycles that it will affect general response times pretty quick.

On the other hand, another site I know and really like (cough, cough), is database-driven but not on the fly. Unlike an application that needs to know how many copies of X are on the shelf this minute, these information lists change only when the author updates them, so they can be auto- or semi-auto-generated only when something changes. This has the advantage of easy editing in one place but as many different "report" pages as the author cares to create. And those report pages could have chopped-up tables or any other interface improvements that can be defined by algorithm.

I would be happy to provide more details for Tony should he be interested. But as his great work over many years has shown, he knows what he's doing.

FTA Michael said:

oldave, I can tell you from experience that generating anything on that scale on the fly from a database (using typical technology anyway) will take a lot more time to transmit and enough server cycles that it will affect general response times pretty quick.

Click to expand...

Not to argue, but I respectfully disagree. I work daily on an application that is entirely database driven.

I will agree that more CPU cycles are used when compared to serving static HTML, but the tradeoff in ease of maintenance is huge, especially if Tony were to consider doing "all of the above" in response to the poll. I also suggest (based on my experience) that response will not be noticeably different (given sufficiently studly server resources... naturally, on a small server, serving HTML will be noticeably faster than running queries and generating pages on the fly).

FTA Michael said:

I would be happy to provide more details for Tony should he be interested. But as his great work over many years has shown, he knows what he's doing.

Click to expand...

Tony does far more than a yeoman's job, and I have nothing but the utmost respect for what he does. My suggestion is a way to make "all of the above" a viable option while reducing the maintenance required.

I did not mean to suggest that there's anything at all wrong with how it is now.

I'll be honest here. There are two reasons why I haven't tried a Database: because whenever I start looking at Access or MySQL and try to figure them out, my eyes start to glaze over and my head begins to hurt! I will not "start from scratch" at this point with close to 10000 entries. To this point, as long as there aren't wholesale changes like the migration to E*10 I can handle manual changes.

Motivation to fight inertia is the other reason.

But, if there is a relatively simple way to port over all the info from the chart to a database, I would like to offer all sorts of options. Specifically, by package, by sat (already done manually), by channels alphabetically, without locals, etc.

The biggest problem is the motivation on my part.

Thanks all.

See ya
Tony

oldave,

First, I wasn't trying to suggest that you were dissing Tony. I was just trying to emphasize that I'm not trying to tell anyone that "my way" is better than someone's else's successful way of doing things.

About the server cycles, I shrug. You can offload the database to a different server or write a true application (as opposed to a script), and it all runs like greased lightning. But if you're using an Access database hosted on the web server and using scripting to construct the page each time, it can get ugly. When a non-developer approaches the problem, their solutions tend to look more like Access and scripting.

I certainly understand the reluctance to spend a lot of time switching over to a new system. Properly done, the database record entry system could accomodate copy-and-paste, so Tony (and his friends?) could populate the database at leisure. When the database was full, Tony could push the button to make whatever list flavors he wanted, check that they came out okay, then replace the old manually edited pages with the database product. Then whenever a change was needed, he'd only need to change the appropriate records and push the button again.

First off the task that tony is handeling and the work he has done is very much appreciated from this side of the fence. Personally I would love to see any changes that would reduce the overall size of the chart. 1MB pages can be issues and do take a long time to load.

My suggestions if some tweaking would be done is if you want to keep the full chart list in take move it to an auxillary location so that it is not what is commonly brought up.

Also, moving the previous 4 years (2005 and back) off that page would help also. Perhaps a History Archive Link makes sense here.

Third, when I am looking up a chart I am most interested in finding my channel by name and then seeing what transponder it is assigned to. At times I also want to know what channels are on what birds. I do like the links to the bird views.

Yes a Database could help here.. but you could also do flat file approach to the problem to remove the presentation from the data. I am not sure what type of resources are on the servers in terms of web technologies so my guess is that would also limit what one can and cannot do.

At one time, I started toying with the idea of providing tables to show what Dish Channels contained proper OTA mapped information with the help of the community but after doing a few states and some feedback I decided to not take the concept further. Lot of maintence so I know this take is a big one and Kudos to Tony for doing the work.

I find the maps within the page too small to be useful, but the links are nice.

I don't like the change scroll, I think that was fine the way it was.

I voted for links only, as the closest approximation to the above.

Really, though, what I'd most like is simply to have Dish channel numbers incorporated into this alphabetic market chart.

Re databases, server cycles, etc.: a database would be easier to maintain, but static html, regenerated whenever the database is updated, is definitely the way to go, unless you also want to provide search and sort functionality. (Which would, of course, be nice, but everything you do takes WORK, and since I don't see anybody offering to pay for all that effort.............)

Thanks, Tony, for all your time and effort on the chart through the years. Much appreciated.