DBSTalk Forum banner

How do you prefer the channel chart?

  • With local maps and links

    Votes: 0 0.0%
  • With links to local maps only

    Votes: 11 23.4%
  • Text only but keep the formatting and colors

    Votes: 15 31.9%
  • Leave the chart the way it was, the frame for changes is okay.

    Votes: 9 19.1%
  • Leave the chart the way it was and stop messing with it!

    Votes: 0 0.0%
  • Other (posted below)

    Votes: 12 25.5%
Status
Not open for further replies.
1 - 20 of 21 Posts

·
Hall Of Fame
Joined
·
6,901 Posts
Discussion Starter · #1 ·
How do you prefer the channel chart?

1) With Local Maps and links
http://ekb.dbstalk.com/dishlist-with-maps.htm

2) With links to local maps only
http://ekb.dbstalk.com/dishlist-with-link.htm

3) Text only but keep the formatting and colors
http://ekb.dbstalk.com/dishlist-text-only.htm

4) Leave the chart the way it was, the frame for changes is okay.
http://ekb.dbstalk.com/dishlist-with-frame.htm

5) Leave the chart the way it was and stop messing with it!
http://ekb.dbstalk.com/dishlist.htm

6) Other - Please post a message clearly stating your idea.

--
P.S. You can vote on it also, BTW :D
 

·
Super Moderator
Joined
·
53,718 Posts
Also (from TNGTony) "Only one or two permutations can stay since each page is updated manually several times a week."


Personally, I like "TEXT ONLY" for the fastest load time ... but would not mind seeing the names of the local markets in large print in the row at the top of each market (text not graphic) to help them stand out.

I could live without the iframe for changes but that does help make sure that changes are shown on both the main chart and the changes page.
 

·
Hall Of Fame
Joined
·
5,345 Posts
Jame's Idea is something to consider. When I have time (not this week) I'll try it on for size and test that out too.

See ya
Tony
 

·
Hall Of Fame
Joined
·
6,901 Posts
Discussion Starter · #4 ·
Would be nice to have all of them - as i like 'em all... :D

(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 :D

P.S.

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

·
Hall Of Fame
Joined
·
3,474 Posts
I'll second JL's suggestion. A pure text, stripped-down version would be a godsend for a lot of dialup users.

The more you can chop the page into chunks, the better. Most folks won't want to see the map of the Kansas City market, or the full list of every channel change this year, so why make everybody wait while you load them?

Not only are the extras-laden pages slow to download, they also put a load on local computers rendering those enormous tables. Chopping the huge table into a series of shorter tables would help there, too.

And having said all this, every bit of that information is cool, and I'd love to see it available. Just one or two clicks away from the main page. :)
 

·
Hall Of Fame
Joined
·
5,345 Posts
Michael,

Just the data is just over 1 meg in size. The chart reneding is a problem especially with MSIE which waits to get everything before rendering the chart. But chopping up the chart is something that isn't as easy as it sounds. I think you sent me an alternative a couple of years back that I lost in a computer crash before I could fully test it, but it was cumbersome to edit on a daily basis.

See ya
Tony
 

·
Legend
Joined
·
192 Posts
I'm not sure why this info isn't all in a database, and the pages generated on the fly from that database - it would make updating it hellaciously easier.

If you'd like to explore that, we can.
 

·
Super Moderator
Joined
·
10,084 Posts
I personally like it the way it was. Very detailed....

So does anyone know the percentage of tech geeks that would want this info that really still use a dial up connection?
 

·
Hall Of Fame
Joined
·
3,474 Posts
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.
 

·
Legend
Joined
·
192 Posts
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.
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.
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.
 

·
Hall Of Fame
Joined
·
5,345 Posts
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
 

·
Icon
Joined
·
1,018 Posts
I would think that there maybe some installable php app that uses a mysql database that would simplify the task, and not have to try and re-invent something from the ground up. While it may not be great because it may not fit the task perfectly, it could serve a purpose for looking up stations and locations quickly..
 

·
Hall Of Fame
Joined
·
3,474 Posts
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. :)
 

·
Hall Of Fame
Joined
·
4,009 Posts
I've always believed that more = better as far as web content is concerned. Gimme everything but the kitchen sink.... Longer load times are a small price to pay...
 

·
622 Tips & Trick Keeper
Joined
·
9,880 Posts
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.
 

·
Godfather
Joined
·
484 Posts
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. :)
 

·
Legend
Joined
·
192 Posts
FTA Michael said:
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.
I understood that :)
FTA Michael said:
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.
Agreed. My thoughts revolve around a SQL server and web server.
FTA Michael said:
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. :)
I'm in agreement here, as well.

Actually, the data's all there, and reduced to a delimited CSV type file, would be directly importable.
 

·
Hall Of Fame
Joined
·
5,345 Posts
Joblo,

When I get bored again, I will add the Dish channel numbers to the locals page. The reason it wasn't done initially is because all the channels moved channel numbers in 2000 and we weren't too sure that is where they were going to stay.

Thanks for the kudos everyone. I am happy to provide the chart and it is fun. Thanks to all the people who send me info otherwise I would not be able to keep up!

See ya
Tony
 
1 - 20 of 21 Posts
Status
Not open for further replies.
Top