Framed UI for more convenient scrolling?

[cincyreds]

Hi,

Thanks for all the hard work involved with EWA development - it is greatly appreciated!

I have a request: Would it be possible to present the web interface as a framed page so that the main tabs would remain at the top of the page while scrolling?

Additionally, it would be even more helpful if the page for the TV Guide were framed so the section down to and including the top header for show times would remain stationary while scrolling. I realize that the header can be repeated every X lines, but a framed page would really be the ultimate.

I generally don't like framed HTML, but I think this is one instance where frames would improve the functionality/usability.

If this is not feasible or too time consuming, would I be able to redesign the source pages myself to incorporate frames, or would this just lead to problems when applying future updates or post processing commands?

Thanks again!



Dean

[UncleJohnsBand]

Hi,

Thanks for all the hard work involved with EWA development - it is greatly appreciated!

I have a request: Would it be possible to present the web interface as a framed page so that the main tabs would remain at the top of the page while scrolling?

Doing the whole thing in frames would not make sense to me.....most of view is fine without framing.

Additionally, it would be even more helpful if the page for the TV Guide were framed so the section down to and including the top header for show times would remain stationary while scrolling. I realize that the header can be repeated every X lines, but a framed page would really be the ultimate.

I generally don't like framed HTML, but I think this is one instance where frames would improve the functionality/usability.

I agree this may be a good use of a frame......I will play around with it and see what I can come up with.....

If this is not feasible or too time consuming, would I be able to redesign the source pages myself to incorporate frames, or would this just lead to problems when applying future updates or post processing commands?

This can become problomatic for you since you would have to add your changes back in with each update to EWA or release of GBPVR. I'll give it a whirl and see what it looks like.....I'll probably post a beta of the guide here when it is done so you may want to monitor this thread for activity.

[fbachofner]

I generally don't like framed HTML, but I think this is one instance where frames would improve the functionality/usability.

I think this could all be done with CSS used for positioning.

That way EWA stays compliant with modern web development standards.

[Although currently this is most important for pages to rank higher in search engines . . . which is not something EWA pages need to worry about.]

[cincyreds]

I think this could all be done with CSS used for positioning.

That way EWA stays compliant with modern web development standards.

[Although currently this is most important for pages to rank higher in search engines . . . which is not something EWA pages need to worry about.]

Good suggestion. As for the whole interface having to be redone, I guess mainly this would be most useful for the guide page as UJB points out.

Thanks for the followup.



Dean

[UncleJohnsBand]

Ok..attached is a beta of a framed guide......just unzip to your GBPVR directory with path enabled.....shouldn't need to stop the service for this one.

Then to access just go to http://localhost:7647/gbpvr/guideif.aspx . I did not remove the standard guide and the guide tab points to the standard guide....for this testing you will need to manually acces the framed guide.

Let me know what you think.

[cincyreds]

Let me know what you think.

Wow - you're fast.

Pretty close - the only thing I had imagined is that, instead of using an IFRAME, the entire page would be framed with the top frame set to a fixed height and stationary (so there would be no scrollbar at the top) and the entire bottom of the page that contains the rest of the content would scroll. This would eliminate the double set of scrollbars which can be a little confusing at first. Or, as suggested earlier, fixed positioning using CSS. Although CSS is more current, I seriously doubt any browser would ever abandon support of frames (even if the FRAME element becomes deprecated). Based on the potential complexity it just seems that using frames is a much simpler approach whereas doing this with CSS might require some pretty funky coding (alternatives?)

So overall the page would look almost exactly like what you have, but without the inner scroll bar of the IFRAME.

Thanks again for the quick followup. I've been working on a new "skin," but I'll hold off until the next version of GB-PVR is out seeing as there may be changes made that affect layout and positioning.

If you're curious I can PM you a screencap of what I have so far. It's far from functional yet, but it would give you a general feel for what the skin looks like.

It's taking more time than I anticipated because once I got into the code I found that so many CSS elements are reused throughout all the different pages. This makes it challenging to give each page unique elements, buttons, etc. etc. As well, the cross-browser compatability is borderline nightmarish due to some non-standard behavior by IE.

Another suggestion: adding more unique ID/name identifiers to page elements would be VERY helpful so that similar elements on different pages could take on their own unique properties. For example, giving each <table> on the different pages a unique name would allow more customization (for example, "header_header_guide" and "header_header_search" instead of just "header_header" for all pages. Of course, the more elements which have unique names would allow for more in depth customization (at the expense of a larger external CSS sheet).

I realize these suggestions would take a decent amount of time and none of this really affects core functionality beyond aesthetics, so if it's too much work that is totally understandable. The time you spend now is greatly appreciated!

Thanks and have a great weekend!



Dean

[UncleJohnsBand]

Wow - you're fast.

Pretty close - the only thing I had imagined is that, instead of using an IFRAME, the entire page would be framed with the top frame set to a fixed height and stationary (so there would be no scrollbar at the top) and the entire bottom of the page that contains the rest of the content would scroll. This would eliminate the double set of scrollbars which can be a little confusing at first. Or, as suggested earlier, fixed positioning using CSS. Although CSS is more current, I seriously doubt any browser would ever abandon support of frames (even if the FRAME element becomes deprecated). Based on the potential complexity it just seems that using frames is a much simpler approach whereas doing this with CSS might require some pretty funky coding (alternatives?)

So overall the page would look almost exactly like what you have, but without the inner scroll bar of the IFRAME.

I'll toy around with it some more and see what I can do.....

Thanks again for the quick followup. I've been working on a new "skin," but I'll hold off until the next version of GB-PVR is out seeing as there may be changes made that affect layout and positioning.

If you're curious I can PM you a screencap of what I have so far. It's far from functional yet, but it would give you a general feel for what the skin looks like.

Sure...shoot me a PM.

It's taking more time than I anticipated because once I got into the code I found that so many CSS elements are reused throughout all the different pages. This makes it challenging to give each page unique elements, buttons, etc. etc. As well, the cross-browser compatability is borderline nightmarish due to some non-standard behavior by IE.

Yep....real fun stuff.....

Another suggestion: adding more unique ID/name identifiers to page elements would be VERY helpful so that similar elements on different pages could take on their own unique properties. For example, giving each <table> on the different pages a unique name would allow more customization (for example, "header_header_guide" and "header_header_search" instead of just "header_header" for all pages. Of course, the more elements which have unique names would allow for more in depth customization (at the expense of a larger external CSS sheet).

The more you grow the CSS file the more complex it is to maintain....the thought was to keep the CSS as simple as possible and allow different graphics and color schemes......having all skins follow one set of values so that there was not a bunch of different CSS variables to maintain.

The current onese should let you change every graphic that is displayed....all text and all colors. I am not sure what more you would need to add.

I realize these suggestions would take a decent amount of time and none of this really affects core functionality beyond aesthetics, so if it's too much work that is totally understandable. The time you spend now is greatly appreciated!

Thanks and have a great weekend!



Dean

Always appreciate feedback and suggestions....that is the only way things ever get better. Even if it takes time to do something if in the long run it provides easier maintenance with more flexibility that is great.....always a balancing act "does the change provide enough value that would outweigh the added maintenance or complexity......".

[UncleJohnsBand]

Attached is an updated Guide with scrolling.....I think it is very close to what you were looking for.

I looked at using the alternate model using the embedded object code. Got it to work in FireFox and then went to IE.....only to learn that IE doesn't support the model....I believe because of the lawsuit they lost last year.

Let me know what you think.