riquezjp / kitchenTV

Kitchen TV; weather, clock, live news feeds & video for Raspberry pi using PHP/javascript
GNU General Public License v3.0
26 stars 12 forks source link

Creating a dynamic, responsive layout for K.TV using Materialize #4

Open JoshuaKimsey opened 7 years ago

JoshuaKimsey commented 7 years ago

So I have been looking into a solution to make the layout of K.TV adapt dynamically to the screen size that someone using. At first, I looked into Bootstrap, but the issue with that is that you have to use Sass, SCSS, or Less, all of which I am not a fan of whatsoever. I also found Bootstrap to be rather difficult to deal with overall.

I was actually stuck on what to do, until a video recommendation in my YouTube feed led me to a video on a responsive frame-work know as Materialize. It's based on Google's design standards they are using with their products. Although it can be used with Sass, the default frame-work uses normal CSS and JavaScript, which are big pluses in and of itself. I also really like the overall design, ease of use, and flexibility of Materialize. I think it would be a terrific way to make K.TV responsive, while not making the project completely uninterpretable to an outside user.

I will leave a link to both the front page of Materialize and the video that led me to it. Look through both and tell me what you think! I may go ahead and try and adapt my fork to work with it, and see how it looks! I'll update the fork when I reach a point of usability. 😄

Links:

riquezjp commented 7 years ago

I guess I am old school. I dont use frameworks, I hand code from scratch. I was loath to use Jquery - ha ha I'm sure this could be good, but it seems like overkill for a 1 page website. I think it just needs some media queries & messing around with & it will resize fluidly. (relitively) I might be wrong, but when I have some more time ill try & sit down & work on that. The current version seems to re-size fairly well for TV-aspects, but not everything is re-sizing (buttons, clock)

JoshuaKimsey commented 7 years ago

I can understand your view on that! I actually take a not to dissimilar approach myself to things like that. In my view, usually if you think you should use a framework to make it easier, either code the framework yourself or make the problem simpler to begin with. However, in this case, I think Materialize offers some functions that would be rather difficult to code by hand, at least for the scale of this project.

We will see though! I'm messing around with it now, so we will know shortly how well it works! When I get it finished, I will most likely just delete my current fork and add the new code to a new one. I'll post the link here when I'm done! 😄

JoshuaKimsey commented 7 years ago

Ok, so it may take me a bit longer than I first thought to adapt the code to Materialize's design. However, after a few hours of playing around with it, I am throughly impressed! The ease of use for creating and customizing components is incredible! When I get a rough example put together, I'll either post a link to the code or post pictures of the test I'm working with.

JoshuaKimsey commented 7 years ago

Ignore this question and see the next post below!

Question for you! What do you think should be the minimum size I should try and make K.TV compatible with? I feel like anything under 720p is going to be rather tough to account for, both size and spacing wise. Technically the "Official" Raspberry Pi Foundation screen is 800x480. However, I sincerely don't think that K.TV, in it's current or Materialize state, would work appropriately on such a small, low-resolution screen. It might be advisable that we do make a version that is specifically for that screen, since I think that's the one most users would most likely have. But, I don't believe that it should be a part of the main K.TV project, as I believe it simply would add too much overhead to the project to be worth it.

JoshuaKimsey commented 7 years ago

Ok, I think this is ultimately going to end in failure. I won't be able to create a version that works for both 720p and 1080p. The biggest issue I'm facing is that with the framework, and apparently most other frameworks, there is no difference for how the program acts with a 720p screen compared to a 1080p screen. According to the framework, the screens are considered "XL Desktops" and therefore treated the same, making dynamic environments for the two impossible. Ironically, as opposed to my last question, I could probably easily make a responsive program for the RasPi Display from the foundation and a 720p screen, that would work fine! Unfortunately, I can't do anything for sizes above 720p...

I may still go ahead and make a version just for a 1080p screen as a proof of concept, which I'll post images or code of here. But, it will be just that, a proof of concept, that won't dramatically improve on the program you've created already, save for a few small additions.

I do have a question for you though! How do you feel about pop-out menus when you click on a button? You'll see why I ask this when I post what I've done with Materialize! 😉

riquezjp commented 7 years ago

There are a lot of display quirks & non-standard sizes in TVs & displays, so it will be tough to be perfect. The TV I use does 720p in a standard aspect, but it also does 1080 however the aspect is changed & the image is "squished" quite a lot. The 1080 mode works with the pi great as it is, but it looks squished. The 720 mode doesnt fit the pi & there are unequal black borders around the screen, part of the screen is off the edge. The pi needs to have its display hdmi display settings tweeked quite a lot for it to fit well (it does work great once you manage it but its a pita) 720 / 1080 is the standard but I bet many are 715, 702, 734, 760 & all that junk

I was thinking though, The buttons at the bottom could be fixed position to the bottom of the display, then the space above them, between the weather, would vary depending on the screen height. A design like that would look more tailored & get around the problem

JoshuaKimsey commented 7 years ago

Ah! Yeah, the Pi doesn't handle HDMI output very well. You can go in and fiddle with the "hdmi_group" setting in the config file for your Pi. I had to do that in order to get mine to output 1080p @60hz to my monitor.

That's not a bad idea overall! I am currently working on adapting some of the Materialize code to work specifically for the 1080p version, but the changes might work well for any screen size! I'll post the results of my work shortly! I think you're really gonna like it! :)

JoshuaKimsey commented 7 years ago

screen shot 2017-06-17 at 1 58 04 am Ok, like the Phoenix rising from the ashes, I have salvaged the remains of my first attempt at making K.TV work with Materialize! Now I have actually achieved something that looks really good and is very functional! The biggest changes are with the nav bar at the bottom, the buttons on the nav bar, and the loading screen at the start.

I'd say about 8 - 10 hours of work into adding those additions, although like 6 of those hours were working with the ultimate failure to port K.TV to Materialize. But in the end that work did pay off with the knowledge of how to adapt Materialize to K.TV's form, than to try and adapt K.TV to Materialize!

Here are the links the the branch with the updated code and to the list of specific commits. I also ran a program called "Beautify" on the code for the index and stream, as to make the code look more "proper" in its spacing and format!

The main branch: https://github.com/hsoj95/kitchenTV/tree/Improved-Code-with-Revisions

The list of commits: https://github.com/hsoj95/kitchenTV/commit/5a480cc69634029fb6d7a779066953ab69b2bbe7

*Edit: I attached a picture of what the finished product looks like! I'll let you run the code to see it fully working! Let me know btw if something doesn't seem to be working right. There's still probably some "Franken-code" left over from the adding and subtracting I did to it.

riquezjp commented 7 years ago

Nice! Really good job :1st_place_medal: I like that menu system its a totally different approach that works well.

riquezjp commented 7 years ago

Small issues i found ~

JoshuaKimsey commented 7 years ago

For the clock, I purposely moved it over to the right to deal with the fact that the index now loads a webpage, Wunderground, instead of a video. It keeps the digi clock from blocking anything on the page. Now, as for it locking onto the page, I do indeed need to do that. I just did a simple solution to begin with in order to move it. You'll also notice that it's only centered part of the time as well.

For the volume button, I actually don't know why it does that, but I assume it has to do with something in the JS that is messing with it. Tomorrow, I'll look deeper into the JS and see what is happening!

I have plans to further integrate Materialize into the clock, but for now, I wanna fix the bugs! Then I'll start adding again, and this time it shouldn't take 8 hours! 😄

JoshuaKimsey commented 7 years ago

Also, the web_browser page, the one that links to DuckDuckGo, is TOTALLY broken! I mean in a way that is completely unusable! However, I didn't actually mess with that page, or it's CSS, at all. So I will probably need your help in fixing it! 😕

riquezjp commented 7 years ago

Ive updated my version with improved CSS resizing. I think this will be almost perfect for any screen 720 / 1080 (or larger) If you notice anything that doesnt work please let me know. Its designed so that the top of the youtube video will be clipped off on short screens, or have extra space on tall ones.

riquezjp commented 7 years ago

well. on my computer using std resolutions 1280x720 1920x1080 it works fine. but on my kitchenTV which is not a std screen size, its not so hot. im not sure what the res is on that screen but it seems like its more square 1280x1080 & so there is a large blank area above the YT video. this will be tough to fix... hmm Anyway, let me know how it looks for you re-sizeing wise

riquezjp commented 7 years ago

found a way to correct for this. In config there is an aspect setting for 4:3 or 16:9 so if you have a square TV you can use the m34 style. for now the 16:9 works best but can add some extra 4:3 styles later to improve that mode

JoshuaKimsey commented 7 years ago

Hmm, interesting! I like that you improved the CSS sizing, and added an option for 4:3 or 16:9. I'll see if I can adapt the code to work with the changes I made to the program!

Were you able to figure why the DuckDuckGo search page was so broken?

JoshuaKimsey commented 7 years ago

Ok, I tried porting some of your changes to my version and it ultimately didn't look very stellar on my 1080p screen. It could just be I didn't port over everything I needed, but I'm not sure.

I feel like we may be trying to reinvent the wheel with you working on responsiveness and me working on adding new features and making the UI look nicer. So I suggest an easy fix for this double work issue! If you like the changes I have made to the UI so far and are happy with how they work, let's merge my fork back into the main branch of your project and let's both work on making the UI responsive. That way, I don't have to worry about breaking something that you already did, and you don't have to worry about accommodating any new features I might add.

Let me know what you think! Right now, my branch of the fork seems to be stable and working as intended, save for the broken DuckDuckGo page, but I don't think I broke that. If you want me to change anything with the UI designs I have made so far, feel free to let me know and I'll change them accordingly! 😁

riquezjp commented 7 years ago

What seems to be broken with duckgo? When I use the search icon tool in the pop up menu it shows duckduckgo with the blue bar at the top. I dont see a problem. Am I missing something?

JoshuaKimsey commented 7 years ago

Huh! Maybe I did break something on my end! I swear I didn't mess with the code for that specific part...

Here's a picture of what I mean! This is what it looks like at 1080p: screen shot 2017-06-18 at 3 40 27 am

riquezjp commented 7 years ago

ok. found the problem. I changed the name of rasp.css to main.css, so that needs updating in the webbrowse.php file also

JoshuaKimsey commented 7 years ago

Edit: ^

Nevermind! Ignore what I just posted! I realized I didn't update the CSS link in the web_browser.php file to be main.css instead of rasp.css! I feel kinda stupid now...

Anyways! What are your thoughts on merging the two parts of the program?

JoshuaKimsey commented 7 years ago

Hey, I wanted to add the same nav bar to the DuckDuckGo page, I was also going to add a forward and back button to the bar for web browsing purposes. One issue I've had is getting the bar to appear properly with the iFrame. I know how it should be setup, but usually the frame completely covers the nav bar or the frame appears way too small. Any idea on how to work with that? 😕

riquezjp commented 7 years ago

hard to say without seeing it but perhaps the iframe needs some negative margin on the bottom to account for the height of the navbar.

or set the z-index of the navbar to be above the iframe - you will need it to be relative or absolute positioned for that to work

JoshuaKimsey commented 7 years ago

Yeah, I'll have to mess around with that more! Thanks for the tips though! I forgot I could do a negative margin, I'll have to try that.

JoshuaKimsey commented 7 years ago

Question for ya! Why do you increment the loop that displays the news feed by 2? Doesn't that skip every other news story?

riquezjp commented 7 years ago

hmm, no idea - ha ha I think that is not needed, maybe i was testing something & forgot to change it back. just use $i++; instead of $I+=2; I also notice the preg_match is starting 920 chars in. I think this is specific to the BBC feed, so I should probably find a more universal way for that.

JoshuaKimsey commented 7 years ago

Lol! That's fixed now! Seems to be running through more stories now! It's up to you if you wanna mess with the preg_match! I say if it works, don't try and "fix" it!