Specifically to the point of the comparatively low reliability / high variation of analog systems: an interesting property of neural nets is that they can be robust relative to noise when trained with the same type of noise witnessed under inference.
Whether or not speed/etc. would be better in the digital vs. analog design-space, it's an interesting thing to consider that neural nets can automatically account for the encoding-medium's variability. This perhaps makes neural solutions a good fit for low power analog media which otherwise aren't useful for classical computing.
+1 to @sillysaurusx's comment. I'd like to add on a recommendation to read The Cold Start Problem by Andrew Chen. It goes into the trials and tribulations of creating a product dependent on network effects.
More than just a problem of no longer having an "artificial" influx of users via HN, you will need to figure out how to build what Chen calls an "Atomic Network" of users who are self-sustaining on the platform. The first step to that end will be figuring out how to attract the "hard side" of the network (i.e. people who find good papers and post them). What keeps them coming back?
I'd highly recommend considering what the smallest network of users would be that could sustain something like Paperlist and what features they might want.
Some questions that might be helpful to get started:
* What incentive does a given user have to return to the site?
* How would a user be drawn back to the site, e.g. RSS, notifications, etc.?
* What incentive does a user have to contribute to Paperlist over submitting to HN, reddit, etc.?
* How do you attract a new user the to site? Put another way: how do you increase the "virality" of Paperlist? E.g. why would someone link to Paperlist today instead of Arxiv?
But if you're searching for specific content it seems to fall into two categories:
A) The content _is_ the UI element that's being covered and the search box moves out of the way.
B) The content _is not_ the UI element that's being covered and you are looking to find something else on the page.
I don't leave the "Find on Page" box open when I'm normally using a page. So when searching I'm not really interacting with that UI, and when not searching it isn't being obstructed... so does this really constitute a UX issue?
There's one detail ignored here. You hint at it when you say that, regarding yourself:
> I don't leave the "Find on Page" box open when I'm normally using a page.
(emphasis mine)
When you have the find UI open and you click on a link within the page, the find UI disappears when it navigates to the new page.
This allows you, for example, to open the find UI and use it until you've reached your goal, then promptly drop the find UI from your mind, focusing on your new goals. It's not necessary to focus back on the find UI to consciously close it. Eventually, it gets "garbage collected", to use an analogy.
But under certain conditions, this isn't the case. The conditions are when one of the page elements you would come to interact with—without otherwise ever needing to bring the find UI back to the forefront of your mind—is obscured. You must now focus back on the find UI, close it, then switch back to whatever you were trying to do.
Alright, I can see the case where someone doesn't habitually close it and stumbles upon a site where it is obscuring. It seems rather mild to me, but I guess I could regard that as a UX failing.
The only solutions that immediately come to mind:
A) Place the "Find on Page" box at the bottom of the window.
Advantages: It would get out of the way for the common practice of placing web UI at the top of the viewing pane. Also the tradition of putting other UI elements at the bottom (namely the download bar comes to mind) means that it wouldn't be too unfamiliar.
Drawbacks: This _would_ put it rather far from it's omnibox UI-sibling and the rest of the prefs UI, breaking some of the association for the UX. It doesn't resolve the problem of UI elements being obscured the bottom of the viewing pane.
Seen also in: I know at least Firefox does this.
B) Have the "Find on Page" UI element displace the page so as to not cover any page UI while "active"
Advantages: Won't cover UI. Potentially more room for search terms.
Drawbacks: Takes up more screen real estate.
Seen also in: I know at least Firefox does this as well.
Alright, so those are potential solutions... what I'm more interested in are the ones I _haven't_ thought of. Does anyone in the HN community have a brilliant solution for how to deal with designing a "Find on Page" UI?
Another approach could be something that sort of resembles B.
When the find UI opens, it has the same effect as displacing the page, the way full-width find bars do. The difference would be that the UI stays as it is and isn't changed into a full-width find bar. The null space to the left and right of the find bar would still allow whatever it's overlaying to shine through.
The only move to make now is figuring out what happens when the user isn't sufficiently scrolled down far enough, i.e., the null space around the find UI when the user is scrolled to the very top of the page is actually void space. What do you put there? I suggest silently[1] extend the scrollable area of the page by adding a quasi-content area. It's quasi-content because it's not actually part of the page--it's just part of the scrollable area. It pulls its color/background pattern from the page's background style.
Another approach would just be to have the find UI extend into the browser chrome, temporarily shrinking the location bar.
[1] being careful here not to set off any events or changing the way, e.g., event coordinates look to script on the page
Yeah... this one threw me for a loop while I was reading the post... then I realized it. In OS X the whole top of the window is a continuous gradient (all the way from the top edge to the bottom of the primary toolbar). So the OP's complaint appears to be that that the Chrome window renders as though it's in Window/Linux instead of Mac OS X even though it has the brushed aluminum look. This also goes for the "Non-native behavior, Native look" point. In OS X you can drag from anywhere on the gradient, while in Chrome it just "looks" like it's doing shiny Cocoa things.
Whether or not speed/etc. would be better in the digital vs. analog design-space, it's an interesting thing to consider that neural nets can automatically account for the encoding-medium's variability. This perhaps makes neural solutions a good fit for low power analog media which otherwise aren't useful for classical computing.
See https://arxiv.org/abs/2104.13386 for an exploration of physically encoding neural architectures.