#project retro

[historyhalls]

During the Cold War, US authorities explored the feasibility of stopping Earth's rotation as a means to thwart Soviet nukes. Find out here about that bizarre plan, code-named PROJECT RETRO, and how catastrophic it would have been if it had actually been carried out.

PROJECT RETRO - America's Cold War Plan to Stop the Earth's Spin to Counter Soviet ICBMs

[blobpost]

Mini Project Retro: Building a a Product Landing Page Page With HTML & CSS

One of my last freeCodeCamp Responsive Web Design projects: a product landing page. Like before, there were some user stories to guide it, an already-built example, and simple instructions to avoid using fancy libraries and frameworks so you can learn the ropes with the basics.

The end result is here.

What I did

I created an imaginary minimalist decluttering service, an idea that came to me in a flash.  It was meant as a parody at first, but I ended up paring back the words and leaving three options for users to choose from.

I researched some pricing table examples on Dribble but took most inspiration from other websites I like, e.g. Aesop. I wanted to find a compromise: what is readable is not usually the most alluring visually, and what is alluring visually isn’t always the most readable or usable. 

Lessons

Creating responsive divs is a challenge

I ended up with three imaginary services to choose from, not knowing this would be a challenges for responsiveness. Given the minimalist design and ample room to breathe between elements, resizing everything inside the box for smaller-than-desktop but bigger-than-mobile displays wasn’t an option. Deleting one wasn’t either ;)

It was stuck with an awkward in-between sizes scenario: for large displays, the 3 items would sit in a flex row. For mobile, they’d be a neat flex column. But in the middle...do I squish the content inside or push the items into a different layout? In a real life scenario, you wouldn’t cut a pricing scheme because the developer couldn’t figure out how to display 3 boxes, would you? Or...would you?

Turns out there aren’t great solutions for the awkward in-between: for example, the Washington Post narrows the boxes ever so slightly on their GDPR consent form and then forces the boxes into a column. 

My solution was to give the individual items a max-width, and push one down with flex-wrap. Given more time, I’d have designed the boxes differently, but at that point I’d already spent a lot of time figuring out their look and didn’t want to invest much further. Lesson learned. 

What I’d do differently

Different designs for multiple screen sizes. This is a recurring theme. I have a mental sketch of how I want things to look, but for these small projects I don’t lay things out in Figma or fancier design tools. It’s more time-consuming but fun to tweak as I go along for now. For something more complex I’d ensure there are appropriate designs for mobile vs. designs for desktop, and the content looks good in all of them. 

Introduce a sizing system. This is the first project that challenged me in terms of CSS, and I read 'Refactoring UI’ after, which made me realize how I could’ve made things more systematic and saved myself time.

Use SVG instead of PNG. I borrowed a PNG for the imaginary company logo, and really wanted to use SVG, but ended up in a rabbit hole trying to figure out how to resize and crop SVGs, which pushed this as a to do for my next project.

[blobpost]

Mini Project Retro: Building a Technical Documentation page with HTML & CSS

Following up on a previous post, I still have remaining freeCodeCamp HTML & CSS track projects. I decided to focus on the technical documentation page challenge. Like before, there were some user stories to guide it, an already-built example, and simple instructions to avoid using fancy libraries and frameworks. 

The end result is here.

What I did

I created a ‘React 101′ documentation page, trying to add some useful text but keeping it short. I’d learned from previous experience that content generation is the most time-consuming part with these exercises. Sure, I could paste something from MDN like in their example, but I wanted something of my own. 

I time boxed it to a 2 calendar days, which really meant around 8 hours of continuous work.

I researched in the form of asking my Twitter community what documentation sites they like, or if they know of good documentation generation tools.

I personally liked the Svelte and Stripe documentation for their layout, ease of reading and color schemes (I’m going through a purple or muted purple phase). I also enjoy documentation pages that come with a version history, which has more to do with their CMS and user experience than with the visual side of things, but it’s a nice touch. 

The community really liked documentation sites from Stripe, Netlify, Shopify (Polaris) and Prisma. Prisma was new to me and a highlight for the ease with which you could transition between the same documentation page, but for a different database systems (e.g. PostgreSQL, MongoDB, MySQL) or programming language applicable to your situation. For documentation generation tools or CMS, Kirby, Antora, Docusaurus and ReadTheDocs stood out. A few other mentions were mkdocs (a static site generator that's geared towards building project documentation). What was more intriguing was that ReadTheDocs had no pictures on their site, which seems like a missed opportunity. Kirby is also quite versatile. 

Lessons

Styling <pre> and <code> is a challenge, and there are few solutions out there (e.g. Prism)

Though the bulk of the challenge was designed to get you to wrestle with relative and absolute positioning, the other biggie I bumped into was styling code blocks without external help. It’s a non-trivial amount of effort to get code blocks to look presentable on a site, let alone nice. Not even Tumblr has a built-in way to display code. 

First, many CSS aspects went into this alone: how to display the code block, appropriate monospace font families, making the code block editable, wrapping and breaking words, dealing with overflow, number of tab spaces, etc. Whew! I tried many permutations until I landed on something I was happy with. 

Second, I learned that by using <pre> you get a line break before the text starts, and there’s no great CSS way to get rid of it. However, there’s a workaround to start the text on the same line as the <pre> tag.

Third, encoding symbols (<, >, &, etc) into HTML entities without special help means using a lot of &lt and &gt and such. I saw a workaround using a snippet of PHP but decided not to for this project. 

Not to mention all the other user preferences, like having line numbers (using JavaScript) and more. A good best practice article dates back to 2013 but is still relevant today. Unsurprisingly, there are several external solutions but the most popular one is Prism, a lightweight and configurable syntax highlighter (not the same Prisma mentioned before). It’d seem that Stripe uses it, and everyone loves Stripe documentation.

Use  <figure> and <figcaption> for ease of reading and accessibility

freeCodeCamp teaches this too; the <figure> element is primarily for diagrams and pictures but also works with <code>. It can optionally have a caption with <figcaption>. 

Not only that, the accessibility can be improved by adding some ARIA attributes on <pre>:  aria-labelledby to point to the <figcaption> (if there is one), and aria-describedby to point to the preceding text (if it describes the example).

Making code blocks editable gives users more control over the snippet 

I learned from the best practice article mentioned before that editable code blocks gain extra navigation and selection controls, like being able to click inside the code and use Ctrl+A to select it all or use Shift+Arrow to make partial text-selections with the keyboard to name a couple. 

Begin with the end in mind: mobile first, large devices later

This is a classic lesson that I carried over from other projects, though I omitted a clickable hamburger menu from this. I entertained a top-sticky, horizontally scrolling menu. But the more I looked into it, the more time this would have added and required more than HTML&CSS, which were the point of the exercise.

What I’d do differently

Add a hamburger menu toggle for mobile. I kept it simple and chose not to display the navbar on mobile since my page isn’t so long. 

Add line numbers to the code blocks. This was brought up in a best practice article, but felt it was outside the scope of this project to add that much JavaScript. Or...

Use a tool like Prism to style code blocks. It seems like a no-brainer, but I wanted to see how far I could get without it. 

Change the colors. I liked this combo but I’ll be the first to admit I’m not 100% sure how to mix things up in a more aesthetically pleasing way. 

[blobpost]

Mini Project Retro: Building a Form with HTML & CSS

Given I recently implemented a form in React, I figured I’d go back to a smaller, unfinished assignment from the freeCodeCamp HTML & CSS track: to build a form. They’re usually pretty simple assignments: you get some user stories that will have tests against them, an example to inspire you, and off you go. 

The end result is here. 

I made a random post-event satisfaction form, and all in all it took about 8 hours (1 day), without adding any JavaScript to it:

Lessons

Placeholder text is bad UX, and not recommended by the Nielsen Norman group and other practitioners. 

It’s in my CodePen because some of the stories require this or else the tests will fail, but seems like the industry has moved on since. It looks harmless but can be confusing for users, especially when it’s used as helper text that disappears as you type. There are plenty of alternatives to various use cases for placeholder text, which include tooltips and better labels above input fields.

Use <fieldset> and <legend> to group options or questions for better accessibility. 

I hadn’t seen them much before, but wanted to experiment with them. They work together to tell screen readers that a group of form fields relate to each other, and to provide a label for the group. Screen readers read the legend before introducing them to the options. On the GOV.uk Accessibility blog, the GDS recommends using them when you have a single multiple choice question, or when you have several questions relating to the same topic -- which is how I used them.

Use <label> to make form fields more accessible. 

The label tag wraps the text for a specific form control item, usually the name or label for a choice. This ties meaning to the item and makes the form more readable for screen readers Bonus: this also means you can click on the text next to a radio button to select it, rather than inside the radio button itself. 

Styling the form took a lot of time (and could’ve taken longer)

It took time to get fonts and colors right. I’m not a designer but I want to make things look decent (if not pretty) even if it’s not a requirement. I worked around this by scouring Pinterest and Dribbble for pleasant color schemes, and landed on just four colors (blue, dark and light grey, and white) and a few variations for the button hover state. 

What I’d do differently

Try a different layout for the fields. There’s more to do to make it readable and accessible, align the dropdowns, and so on. 

Different and custom styling; I could spend forever on things like custom checkboxes and radio buttons but decided not to for the purpose of this exercise.

Make the form responsive. This wasn’t a requirement, but I’d go back in and add it later. 

[ffortissimooooo]

Visit Original Link

made to loop and made to hoop