Domain-wise, I can't really think of anything good. I own ephemeral.place from an old experiment, so maybe phrases.ephemeral.place. Maybe something better will come to me.

Weekly Retrospective: Jan 18 - 24

Last week:

▣ Fixed page buttons

▣ Added # of votes, then removed them

No real progress this week. Figured I'd work on some other things since this project is so ahead of schedule.

This week I really do need to do these things:

□ Documentation/about page

□ Figure out a better hover indicator on buttons

□ Domain name

□ Deploy

Weekly Retrospective: Jan 11 - 17

Last week:

▣ Codified the interface in a high fidelity design

▣ Added a second view for underused words

▣ Implemented the interface and functionality

▣ Containerized the client/server

Most of the implementation is now done. I haven't come up with a ranking algorithm, but to be honest I'm not sure I really see a need for that anymore. I can't imagine this site getting enough traffic to warrant adding weight to submissions over time. Perhaps number of votes is good enough.

This week is more about any remaining cleanup and polish. Maybe a couple of additional tweaks here and there, but I think it's mostly where I want it to be before putting it online.

This week:

□ Documentation/about page

□ Design/add any additional feature richness, perhaps through the use of some kind of "examples" field…

□ Figure out a better hover indicator on buttons

□ Domain name?

□ Deploy?

Really appreciating all the shorthand ways of passing props down in Svelte:

<Random type="overused" {...json} {api} redirect />

Versus with React:

<Random type="overused"
        items={json.items}  
        nextPage={json.nextPage}  
        api={api} 
        redirect />

Simple changes like this make it so much nicer to work with.

Spent a while trying to figure out why I couldn't run the docker stack on my laptop but it worked fine on my machine running Ubuntu. Then I discovered:

https://github.com/docker/for-mac/issues/1031

Nice lil issue not at all mentioned in the documentation. This dude sums it up nicely.

In some sense the core is "phrases I'm tired of hearing" but the website makes it "phrases we're tired of hearing" in a more collective sense. So voting on something is like agreeing that it's overused, that you're checking it off as something you agree with. A vote is an agreement to the statement; it's a phrase you're tired of hearing. Perhaps the checkbox is the best way to think about the voting mechanic…

Weekly Retrospective: Jan 4 - 10

Last week:

▣ Defined the website I'll be developing

▣ Worked on designing the flow and functionality

▣ Moved to creating very low fidelity digital versions of the interface

▣ Built in the basic functionality as an intractable interface

Overall feeling OK with the progress thus far. I originally set aside 2 weeks for implementation but I ended up spending about four hours on Saturday and got most of it done. So far the goal to keep things simple is holding up in practice.

This week:

□ Figure out final interface design in hi-fi

□ Implement interface

□ Define sorting algorithm and implement

I'm gonna start working on getting some functionality in and come back to the interface styling and exact layout later.

The sorta neo-brutalist-but-still-playful thing as seen with The Markup or FiveThirtyEight could be one approach.

I still don't have a very clear idea about how this website should look.

January: A Repository for Overused Words and Phrases

I'm not sure how it happens, but there are certain phrases that catch on in a way that feels… unnatural. It's like there are certain phrases manufactured to perfectly frame a particular subject, but perhaps in a way that's too perfect, too well considered. You hear these phrases all the time, but when you hear someone you know say them you think "that's strange, you've never used that phrase before and yet I've heard it all the time." I certainly do at least. Seems like others may have as well.

The idea is that this website serves as a repository for these phrases. So the necessary question: why a website?

Part of the quality that these phrases is that they're based in a particular moment in time. An event might trigger them, or they'll be used to the point of people becoming a bit too aware of the trope. So there's a sense of change; the overused phrase of this month could be different than that of the next. There needs to be some way to keep track of change over time.

Another consideration is that these phrases must be recognized as being overused. Maybe I think the phrase "the new normal" is overused, but unless others agree it's hard to say. This is a good application for some kind of popularity metric, which will be an interesting change of pace for me. Regardless, the point is that there should be some degree of intersubjective agreement on the phrases. Some kind of technology could help with that. A website feels fairly natural.

How will it be built?

For this site I think I'll start with a standard REST API built with express. The frontend will be built with svelte, since I'm still learning the framework and would like to improve my skills. The implementation should be fairly straightforward, the tricky part comes from keeping the actual functionality as minimal and essential as possible.

By next weekend I will need to have figured out the primary affordances and features and have designed the interface. That gives me two weeks to implement and an extra for when stuff goes wrong. This month I have about 4-5 hours to spend each week, so something like 20-25 hours total. Seems doable.

Twelve Websites

I like to make websites. I've made a lot of them in the past.

It takes a long time for me to make a website. Depending on the reason for making it, I often spend most of that time thinking, implementing something, changing my mind, and repeating the process. Sometimes I start with an interface in mind, but often the reason for creating the site evolves as it takes shape, so I shift what the interface is and refocus. Despite how long this takes, I like it because it means I get to spend a lot of time engaged in the experience of making. The process is, after all, the whole point. The end product is often not that impressive or interesting.

I'd like to force a different way of approaching this. I want to see what happens when I am bounded by a timeframe; just one month to turn something that could be a website into a website. I have a very constrained amount of time to dedicate to this project, probably somewhere around 2-6 hours a week. That will require that what I make is simple in concept, design, and implementation.

Of course this means what I make each month will be the product of less than 25 hours worth of effort. I don't want to make a shitty versions of what could be bigger websites, I want to make websites can be complete in less than 25 hours worth of effort. That means SIMPLE.

To be honest I have no idea what simple really means in this context. The point of this project is to figure that out. What is simplicity in design, implementation, and process?