š Redesigning and rebuilding my Web site from the ground up
source link: https://www.sarasoueidan.com/blog/redesign/?ref=sidebar
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
š Redesigning and rebuilding my Web site from the ground up ...and in the open
This article was published on Apr 1, 2021, and takes approximately 8 minute(s) to read.
Itās about time my Web site got a complete makeover. Itās going to be more than just a fresh coat of paint. Itās going to be a complete rebuild + redesign.
Iām going to rebuild this Web site from the ground up, starting with a fresh, clean slateāan empty repository, with nothing imported from the old one other than some content, such as my blog posts, list of past speaking engagements, and smilar content that will not change in the future. And some images, of course. OK maybe a few other content elements. But you get the point. A new start. A new Web site.
Why start fresh?
Because I havenāt updated the code on this Web site in years.
Iāve been teaching best practices in front-end development for years, while also letting my Web site fall behind on all of them. I havenāt been making time to update this site much aside from adding articles and speaking engagement updates. My first CSS Grids application was on this Web site when CSS Grid was still a new technology, not yet supported by all browsers. That was probably the last major CSS update I did on this site.
Refactoring the current code would take more time than rewriting the whole thing from scratch. The markup needs a fresh start. So does the CSS. And I like fresh, clean starts. I enjoy starting from zero. And I feel like the site is at a point where it would benefit more from a clean start than a refactor.
But why am I writing about this? Why didnāt I just rebuild and redesign this site and just deploy it live, announcing the update when itās done? Because this time around, I am going to go about doing that in the openā¦
The (Open) Plan
I am going to rebuild this Web site in public. While I do that, I will be documenting the process of building it from scratch, sharing a behind-the-scenes look at my work. If you follow along on Github, you may see this Web site come to life one small feature at a time. One small piece of code at a time. I have a plan for how Iām going to approach doing it in a way that works for me, and is a little more useful for anyone who follows along.
Why? For no reason other than trying out something new. And several people have expressed their interest in my dev process. While I do feel nervous about it, I think the benefits of doing this in the open outweight the disadvantages.
The new site will live in its own new repository, separate from the current Web siteās repository.
While it is work in progress, it will live on sarasoueidan.dev. So this Web site youāre on right now will still be here while the new one comes to life. Once the new site is done, it will replace this one on the dot com domain.
Timeline
Since the current site will be live throughout the entire process, there is no pressure to get the new site done quickly. I will dedicate a few hours per week, mostly over the weekend, to work on it. I donāt have a deadline in mind. And I donāt want to create a deadline because I donāt want this work to affect the time and effort I dedicate for my client work. So, no pressure on what will be finished when! It may take a couple of weeks or a couple of months. Maybe more. Maybe less. I am constantly reminding myself that this is my Web site, and I have full autonomy to decide when and how it will get done. āUnhurried Developmentā, as Bernard calls it.
At this point, all Iām planning to do is document the process of building this site from scratch, blogging (hopefully) consistently, in small bursts, as I share the process from start to āfinishā.
Process
All the work on the new site will, naturally, happen in a repository which will be hosted on Github and deployed to Netlify. My favorite part of this entire plan has to be the part where I use Github Issues as a blog. Kind of.
For every new feature (or set of features) I want to add to the siteāno matter how small, like adding a Favicon, for exampleāI will open a new issue and create a corresponding branch where the work on that feature will happen.
I will basically produce a(n) infrequent stream of short āblog postsā in the form of Github issues. The live code for each issue/feature will live in the issueās corresponding branch. As someone who tends to do multiple things at once, this will take a lot of organization and discipline, and thatās the challenging part for me.
So, each issue corresponding to a feature will be where I dump my brain about everything related to adding that feature. I will document learnings, resources, links, etc. along the way. I will write about the thought process, decisions, and struggles if any (kinda like what I did with the Glyphhanger article). So, if youāre at all interested, you will really be able to follow along with me as I do this. Youāll be able to read (some of) my thoughts, and learn from them if you want. Youāll not just have code to look at, but youāll get the entire behind-the-scenes of it.
A Note on copyrights
At this point it is important to note that this opennnes does not mean that I am making the entire repo/site available to copy-paste. It is still not OK to steal other peopleās work just because it is out in the open. This Web site has lived in a private repository since the very beginning. And for good reasons. I canāt count the number of times people have asked to use my Web siteās design for their own Web sites. Iāve even seen individuals copy-paste some of my content (like the contents of my Hire Me page) and use it on their own Web sites. While this is a great testament of the work Iām putting out here, it is not acceptable and I am not OK with my content and design being ripped off like that.
On the other hand, the front-end code I will write to create the site will be open and publicly available for anyone to use, as long as it does not include the actual content it hosts and is built around.
Speaking of contentā¦
New content & Styles
I want to add content. Lots of it! And Iām not just talking about new articles. Iām talking about new types of content. And I want to remove and archive other content.
As for the design, it will change but not drastically. I quite like a lot about the simplicity of the current design, and will mostly be working on adding more personal touches, similar to what I did with the horizontal rule styles. The underlying CSS, however, will be completely rewritten.
I want to create a new layout around the contentānot the other way around. Iām rethinking the content, structure, and architecture, from the ground up. In fact, I will be thinking less about the design and more about content architecture during the process, and am planning to get a functional site up well before any design is applied to the content.
New Static Site Generator (SSG)
After a few years with Hugo, Iām making the switch to Eleventy. The current state of things is a little less flexible than what I would like it to be. Hugoās structure limits my ability to do things with the content that I am planning to do. Thus, Iāll finally be making the switch to Eleventy. (So you can expect quite a few Eleventy content/articles in the future.)
Iām not new to Eleventy, mind you. Iāve used it to build a few client Web sites before, including the 2018 Khan Academy Annual Report.
For the past few years, Iāve been using and loving Hugo a lot. But Hugo is an opinionated SSG. And for the past few years, that opinionation has worked for me quite well. But at some point, I needed a little more flexibility as I want to get a little more creative, particularly with a few layouts. Sometimes I want a page to use a special or unique layout, and Hugo doesnāt make this very easy to do. Eleventy, on the other hand, does.
Hugo is also opinionated in the folder structure it expects. While that structure has suited me very wellāin fact, Iāll be using some of the same structure in the new setupāI also want a little more flexibility in the way I organize and create my collections. The new content and layout structure I have in mind needs a more flexible SSG, and Eleventy is just right for that!
Whatās next?
I donāt want to worry too much about what comes after. Do I turn the process into a series of edited blog posts? Do I just import the Github issues into my blog? Do I create a small video course in which I go over everything? Do I create a case study talk? I donāt know. Maybe. Possibly. Probably. But to be frank, I donāt want to think about that part too much. I want to focus on now, and what I want to do next, and worry less about what comes after.
Youāre welcome to join me on this journey. If youād like, of course. No pressure.
Thank you for reading.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK