This week was interesting. Going back and forth with the gallery took a significant amount of time. From going back through the tutorials to finding helpful YouTube videos and W3Schools pages that offer a plethora of avenues to reach the same (or similar) goal, I think my biggest issue for this week was mass overload.
I think my biggest issue was getting the script to work inside of the container but outside of the individual images, I believe. After a while of taking a few steps backward to take one forward, I saw that the code for the script was already built, along with the container, but I ended up not being sure which code canceled out the previous.
It then made me wonder about how content management systems are built (in this case, for photo galleries). I understand having a resize function to make featured images consistent, which I initially pursued but resorted to sizing in Photoshop, but what about changing the number of images available in the gallery? After I figure out which code to delete, I’d like to know the basics around a photo being added to a collection and the container expanding (or contracting) to accommodate for different final products.
A bit of a tangent, at the three news organizations I’ve worked, I haven’t seen a wholly aesthetically pleasing gallery that fits and works neatly within a normal article. I have seen and used sliders for posts designed for the slider to have preeminence on the page, but the gallery function toward the middle of the page below the A section of an article is often very basic or clunky. And most news organizations I’ve seen generally rely on single images within the text to avoid addressing it, which leaves image heavy stories lacking in ways that simply linking to photo gallery pages (which statistically aren’t clicked at large rates) aren’t the solution.
I think linking the CSS and jQuery pages to change multiple aspects using jQuery at the same time is a breath of fresh air. All the while, as the lessons noted, it still presents the possibility of things getting even more hectic within the page (if they’re not grouped/organized separately and intentionally). The mouseleave functions in the lessons were also really interesting. And the .animate( ) function is a neat tool. I haven’t thought much about how the standard practices incorporate significant design insight.
I remember in class, I believe someone asked why we would intentionally have a hidden element that would be unhidden upon the user’s activity. The mouse hovering over the menu button in this case was a time for using it that I had not beforehand thought of. Toggling the fade elements for the add to cart design is another interesting function.
Reviewing the DOM method was also good. In addition to that, specifically targeting descendant elements and excluding others.
I’m looking forward to working on and finishing my profile. My web developer is with Facebook, and his company’s attention to all of the aforementioned possibilities in crafting visually appealing and intuitive websites is verified by the amount of users that it has worldwide. That, and the criticism it receives after the slightest update or change.
Seeing how if/then questions are answered through programming was also interesting. I always knew that behind responsive design, some programming logic has to be in place for the page’s display to adjust to whatever the user is doing. Starting from smaller if/then statements and then building and adding conditions for more complicated, data-laden graphics is neat, and it gives me a whole new appreciation for the work my office’s developers do on a daily basis.
Other than that, I am appreciative of the in-depth comments on my previous assignment. Things are looking much clearer now with regards to page organization. In fact, I was originally not as concerned about having clean (perfectly and consistently indented) text on my code page as long as it works. Now, I see that unorganized work (even if it displays exactly what you’re looking for on the front end) is a bad habit that will result in unnecessary frustration as the page gets more and more jumbled.
This week was interesting. It was good to have the chance to apply all of the HTML and CSS skills we learned from previous lessons. And I love how user friendly the lessons are after we complete them, allowing us to review past work. Formatting the page and figuring out what I need to add (tags, for instance) was not the most difficult part, though.
I think the most difficult part was figuring out all of the necessary steps for GitHub. I went through some tutorials online, and most of them pointed me in the direction of a few steps not discussed in class (Terminal), and it is a bit challenging when you know the major steps but a few minor steps in between are fuzzy. Regarding the readings, I think I was able to get everything up OK with refreshers.
Going back to the lessons, I think it was the “A Closer Look at CSS” lesson that provided a great example in the beginning about such a seemingly minor step (not linking the HTML and CSS pages) taking away the design of the entire page. The page on selectors was really helpful, as well. It answered questions I did not yet have, and it gave shortcuts (p, h1 designating the same thing instead of two different ones) that seem minor in the beginning, but offer large returns regarding time saved in large projects toward the end. And noting that we use !important as sparingly as possible is also… important. As it could be near impossible to figure out why, given the natural evolution of a webpage over time, specific elements are unnecessarily stagnant.
I think I just need to reread some of the lessons, especially the GitHub tutorial, to solidify and mature the seeds that have already been planted. I’ll do that some this week, in addition to the assignments for this week. Hopefully this is just an introductory learning curve that, just like FromSoftware games, I have to get over to git gud and be successful.
This week’s assignment was good. It rekindled my burning frustration with forgetting to close p tags, but the Codecademy setup was so intuitive that my questions were resolved almost immediately. I remember using W3 for learning to code in one undergrad course, and the user-friendly nature of this homework workflow (at least, so far) is far easier than editing in a notepad locally and refreshing the page.
I do agree, as you noted, you’ve got to practice a decent amount every day to build your skills and grow without forgetting too much in between down time. That’s not unlike music (or Mandarin and Spanish, which I haven’t practiced in years and have thus forgotten.) I’m glad that the Code Academy assignments allow you to reset them for practicing them further.
Regrading our websites, I would want to make a music review site where music is catalogued by genre>artist>album>year. It would be a mix of niche interest, personal and business. I already have some form of cross-page organization in mind in addition to that general hierarchy I just mentioned. The purpose of the website would be to show album art, an artist’s full discography, include references (at the bottom of each page) to similar artists and other purposes. I think it’s somewhat of a wiki page that is more in-depth, adding personal review sections as supplementary elements after straight factual info.
I’ve found the learning curve for programming as an overbearing writer to be both challenging and potentially rewarding.
Of course, there are the similarities in thought processes between copy editors and programmers (e.g., Brian Schlansky using his editing habits to carefully read each line of code). And, as a large portion of the “Rethinking our Thinking” post cleverly and reasonably detailed, coders are in many ways like editors. But copy editors are often the worst enemies of writers.
Some of the 17 rules of Unix Philosophy are anathema to the laws of good writing (Melville, Churchill, etc.). “Clarity is better than cleverness” and “Design for simplicity” to name a few. Having the habit of condensing lines to the bare necessities — and potentially breaking the entire code with a single character out of place — is also frightening to writers, yet common workflow for coders.
What I see as potentially rewarding is the benefit that journalists could gain in learning from programmers. Software languages — like human languages — have developed from Autocode to iOS, and that matters because we as future programmers should know that everything is fluid and able to continually evolve. And although coding often requires linear, step-by-step thinking (similar to the infrastructure of the internet) when compared to writing that is often tangental and more loosely flowing from beginning to end, there is still a progression of thought and purpose for the finished product.
After completing the readings, I still don’t believe that writers are programmers. But I do believe that writers and programmers have the capacity to be journalists. I have faith that the end goal of both draws on some common ground between the diametrically opposing belief systems. When writers use their words and images to tell stories, programmers rely on design and page hierarchy to tell you what’s important. Perhaps, just as there are many forms of writing, a visually appealing article page could be equally as effective in enlightening and entertaining an audience — even when compared to a Shakespearean play? Ah! There’s the rub.