I prefer doing a simple sketch by hand or stylized (like the one I shared) to avoid getting used to a style and then getting stuck to it on any iteration.
To me mockups should be to plan and understand how a pure interface works best and nothing more.
I compare designing then as playing with index cards, you shuffle them, fold them and overlap them.
This is something that those tools never helped me do easily.
Regarding CSS, the general rules on CSS often seems complex but once I started using Suit CSS on plain projects (or BEM if you prefer) and CSS Modules with bundlers plus dropping any kind of framework, the only limitations became how CSS worked natively.
I also started using CSS Flexbox and CSS Grid for anything on layouts and all my problems vanished.
I also use CSS over JS for most of my interfaces, instead of replacing a section I just hide or move it with CSS allowing me to change many parts by just switching a simple class.
(#vbpdcvq) @prologic@twtxt.net Hmm, if I post a message and then itās gone when I reload the page, or if the message I replied to has gone, thatās definitely a bug from the UX point of view š ā¦ but perhaps unavoidable in a distributed system. But since weāre both on the same pod, I donāt see why thatās an issue? Or is this pod itself running on some kind of distributed architecture?
(#tuizh4q) I guess I should go read the code before asking too many questions, but Iām a little puzzled why the same issues with a feed being huge donāt present an issue every time you want to poll for updates? Particularly with the apparent convention of the newest posts being at the bottom of the file.
As for pagination, sure, it can be hard, but why would it be harder in this case than in the cases where Yarn already does it?
(As for infinite scroll, if you have pagination on the server side already, itās trivial on the client side. Yes you need JS of course, but not a lot)
I have a soft spot for CSS for itās simplicity and flexibility.
Iām not much of a UX/UI expert but I love searching for design and concepts and sometimes end up putting together fun ideas just for building something that ālooks/feels niceā. š
(#tuizh4q) I also totally get whet youāre saying about a twtxt file potentially growing to be huge. I guess that, and the fact that itās necessary to work around it with a significant caching architecture, is a major downside to the model of twtxt itself which I hadnāt considered.
(#tuizh4q) Iām clearly going to have to take a proper look at the code and get a feeling for the data architecture to understand this! From the outside I have to say if something as simple as ādisplay all of a userās postsā is impossible ā especially when a twtxt file is literally a list of all of a userās posts ā it feels like some very strange architectural choices must have been madeā¦ but I am also well aware that a lot of painstaking thought by very clever people has gone into this, and I havenāt even looked at the code, so donāt mind me š
(#2kj5qta) @carsten@yarn.zn80.net Yeah, I looked up at a bunch of Twitter UI redesigns on Behance and Dribbble to understand how they tried to āimproveā the app and took what felt nice to me for the #pwa
For me an ergonomic interface is very important and keeping in mind the various ways to use a touchscreen + the desktop interface, I kept the possibility of having multiple layouts to switch to the userās liking.
(#fe55h2a) @carsten@yarn.zn80.net I checked it too, seems that it has a m.request that use the old XMLHttpRequest but expose a fetch style API by wrapping it in a Promise.
That I can understand (though to the extent that I understand it, I think I disagree with it š). I was asking more about the technical barriers @mutefall@twtxt.net mentioned.
responses are provided from the cache
I see, so weāre taking about an architectural limitation in Yarn, rather than twtxt. Still, I know cache invalidation is famously hard, but surely an intentional page load from a user trying to view a feed that isnāt (fully) cached is about the best signal you could get to fetch that data from the origin? š¤
(#x6zqkha) @prologic@twtxt.net Hmm but if youāre self-hosting the bridges (the only option I think since they generally have to run on the same machine as the Matrix server) that man in the middle is yourself š
Of course you do have to trust the code, but itās all open source.
(#tuizh4q) @mutefall@twtxt.net@prologic@twtxt.net I donāt understand this answer at all from a technical perspective (leaving any philosophical arguments aside). A twtxt file is literally a flat file containing a list of all of a personās posts. Surely simply displaying all of that personās posts in Yarn should be the easiest possible thing to do, way easier than threading etc. Why would it require āinvesting heavily in infrastructureā or for the protocol to be āredesigned from the ground upā?
Iām guessing Iāve misunderstood what youāre saying; can you help me understand?
(#x6zqkha) @prologic@twtxt.net but if you used those external services directly without bridging, youād still have to trust all those things, right? Take, say, FB Messenger. Whether I ābridgeā it to Matrix or use Messenger directly, I have to ātrustā Facebook (ha ha, as if! š) Same for Signal, WhatsApp, IRC, or anything else you bridge to.
That said, I donāt really use bridging much; for the services I tried it for it was too much hassle making the bridge work for it to be worthwhile.
(#ooxps7q) @darch@twtxt.net Thatās my approach, yep š ā but I can also see @prologic@twtxt.netās argument that Matrix is over-engineered and current servers are resource hogs and (arguably) hard to get set upā¦
(#5pe3caq) @prologic@twtxt.net for real. Sounds like the whole meeting should have just consisted of them sharing that one piece of information, instead of buying it in vaguely reassuring filler text on a screen.
(#4uape5q) @prologic@twtxt.net I think thatās approximately what happens behind the scenes, it shouldnāt be visible on that easy to the end user, so I guess something else is going wrongā¦ (or bad UI in the client youāre using?) š¤
(#4n4ppya) @prologic@twtxt.net Iām curious about this. Surely the implication of a twtxt file being self-hosted (unless youāre using someone elseās podā¦) is that I control its content; I can delete/edit what I want. Sure, someone else might have saved/cached it, but the same would apply to any web page: if itās on my server, I can delete the canonical version. Doesnāt mean every trace is immediately/permanently gone from the web, but any remaining cached versions are just outdated cache artifacts. Am I wrong?