Hacker News new | past | comments | ask | show | jobs | submit login

OP's setup looks actually pretty similar to my one, though where the pinephone really - really - shines is pentesting.

The compatibility with external Wifi USB adapters and BT hardware like the ones from scott's gadgets make it an amazing pentesting device.

For serious mobile-friendly usage I don't think that we can build UIs the way they're built on Linux systems anymore.

I challenge every defender of that GTK/QT crap to build a swipeable sidebar into their native and responsive UI. If it takes more than 10 minutes, you lost, cause that's what it takes to use CSS, even without any IDE or toolkit.

I wish GTK wasn't built inhouse and would focus on using established toolchains instead of reinventing their own programming language ecosystem with every new release. Nobody wants to use vala. Nobody wants to use glade. Nobody wants to use any of the ecosystem, because it's much more pain than any established UI framework's methodology.

There's a reason why everyone uses electron, and the reasons are not the same why you think your GNOMey toolchains matter. And this has to stop. Otherwise everybody will hop on QT at some point.

I still hope that webkit, javascriptcore and nodejs can be combined into something that allows to easily call C-ABI compatible libraries without 300MB of build size like electron. [1]

[1] https://github.com/tholian-network/retrokit




Worth noting that it's not just the technical end of UI construction that's lacking. Many open-source web projects have crappy UIs, too. I'm a long-time full-time developer, decades-long linux user, and also wrapping up a BFA in design, so I think my perspective is pretty balanced, here.

With amateur developers, their code becomes less reliable the further you get from their development environment. The effect is similar the further you move from a developer's primary keyboard/mouse/big screen computing interface. The difference between interfaces intentionally designed by specialists and functionality exposed through a GUI by a developer becomes more consequential. Sadly, most open source projects not run by larger funded organizations are kind of allergic to usability contributions from domain specialists, so that knowledge just doesn't get rolled in like it does with commercial projects.

Most of the other developer/designer types I know don't even bother submitting design and usability improvements to open source projects. It's just not worth fighting people to make their software less awful to people who aren't already experts in it. It's a lot of work to put into something that will just get bikeshedded into oblivion by people emotionally attached to a bad ui. I don't know any developer who'd submit code to a repo controlled by people hostile towards code improvements, either.

The Nielsen Norman group has some good stuff on usability within hierarchical organizations— I'd love to see similar organization-level reasoning about this stuff for small dev groups. I'm positive these two adjacent and necessary roles can function together without a product manager saying so. In their original usability matrix, "developer-centric usage" was directly above "usability hostile" but they've combined those categories, and especially with non-desktop platforms, that's absolutely the right move.


> submitting design and usability improvements to open source projects

What format does this take. My experience is that more often than not, design and usability improvements are abstract (mockups) and requires implementation by someone else. If the improvement is a working update to a QML file that improves the interface, I'd say chances are that it would be received well.

Sorry if this sounds defensive, but

> bikeshedded into oblivion by people emotionally attached to a bad ui

doesn't sound fair to me.


> submitting design and usability improvements to open source projects What format does this take. My experience is that more often than not, design and usability improvements are abstract (mockups) and requires implementation by someone else. If the improvement is a working update to a QML file that improves the interface, I'd say chances are that it would be received well.

UI design as a discipline fundamentally assumes the person designing the interface doesn't intuitively understand what's better or what's worse— they should investigate, check, and confirm their strategies. Someone posting wireframes is almost certainly looking for feedback to test/refine their approach before they start coding because fixing is a whole lot more work in code than on a wireframe even if they can code. If they can't code and nobody feels compelled to implement it, then that's that— just like any other feature on an open source project.

As an aside, I get flack from other developers when I say designers and their contributions are usually considered less valuable. When I don't, "surely we couldn't suggest existing contributor's spend time on such tasks" is one of the first responses.

Thoughtfully facilitating task completion for humans vs exposing software functions in a UI is like designing good, scalable, maintainable software vs. making functions valid in a programming language that generally work together to accomplish a task. Consider an architecturally unsound project coded by folks with the most rudimentary development skills. Would you try fixing it in bite-sized PRs vetted by the people who made it— none of whom see a problem with the way it is? Even starting such an undertaking would be pointless.

Similarly, the chance of any significant usability improvement being miscible in the standard flow of bite-sized PRs isn't great. If a project is on year 7 of using their undesigned UI, most logical steps between A and Z, even if the code is functional, have broken interfaces. What are the chances of a project going with the flow, there? You'd need to love that software more than your spouse to take that on.

Beyond that, good usability is fundamentally informed by user needs, not architecture, library features, the existence of other elements, or developer preference. Also, UI changes are often fussy, require a ton of testing, and result in a ton of work that doesn't show up in the final code. That's true for all code to some extent, but developer reviewers see it more easily in a clever little algorithm than organizing elements in an input box. That makes them less likely to get the weight they deserve when encountering conflicts, even if the conflict is an uninformed opinion that nobody else around is informed enough to counter. I can't imagine any developer submitting code to a repo where the tables were turned.

> Sorry if this sounds defensive, but >> bikeshedded into oblivion by people emotionally attached to a bad ui > doesn't sound fair to me.

Not really sure how to respond to that. People are worse at taking critique for skills they aren't confident in. Ever give a brand new developer a code review? Yeah. That’s about what it’s like critiquing an open source project’s beloved “quirky” interface.

Even users become attached to bad interfaces because they put in the effort to learn how to use it and assume everybody else matches their use case. It's like bad UI Stockholm syndrome. I cite any discussion where people express frustration with the interfaces for git or Gimp. Even implying they aren't on par with the usability of commercial offerings, let alone insufficient for their basic tasks, will get you flamed.

I've seen this hostility many places, but I can think of one moderately popular app in particular that many non-developers come across. It's function requires fast, smooth input, and to facilitate that, has native clients on most platforms (including mobile) and is modestly funded by their very affordable, optional cloud storage service. In their discord board and issues, even contributors complain about clunkiness, counter-intuitive flows and inconsistencies between clients. Responses range from "eh, it's in the docs" to "it's idiomatic in that OS and totally unavoidable," to "yeah, we should really figure that out. It's on the usability project board." Actual usability discussions are rudderless, shoulder-shruggy, and fizzle out with things like conversations about which font people find most readable. I thought it would be a great place to contribute my expertise. I did one more search searching the forum for 'wireframe,' and every. single. thread. started by a designer posting nicely documented proposals w/user flow diagrams or mockups specifically asking to __kick off a conversation__ about how a more thoughtful UI might look was unceremoniously buried with comments like "what do you expect anyone here to do with this information?" and "the X to close that window is unnecessarily large according to X guidelines and XYZ elements are too close together, etc." and "please don't ruin my app by making it pretty."

If they were non-technical people talking about a technical proof of concept you posted, would you take the time to break it down into tiny bite-sized PRs and submit them? If most projects you wanted to contribute to acted like that, how soon would you stop trying? It's just not worth the hassle until design knowledge and labor are more valued, fundamentally.


It sounds like you've had some bad experiences, sorry for the bad ones :( I've had my own experiences and perspective, some good some less so. It's important to remember that making anything concrete requires tradeoffs to be made - ie less clean code to address edge cases, more complicated UX to accommodate important features, less functionality to increase UX, etc. It's always on a spectrum of completely ideal vs really crappy. For code and UX. I've been on different parts of that spectrum, but I think I caused the more harm than good when I went close to the edges.

I don't really know where I'm going with this, but do know that your expertise and labor carries value! And finding the right place to contribute can take some time.


Not many bad experiences— I looked before I leapt. It's not a hard resource constraint in many cases— the resources just opt out of contributing. Despite the unicorn moniker, many designers know how to code! I've worked as a full-time developer for 12 years, and did comparatively simple but non-trivial systems-focused scripting in sys admin/support roles prior to that. Especially among more UX-oriented designers, most started in other careers, and many of those careers were related to software in some way. A developer I worked with until recently had a BFA in New Media from a top-tier art school. Most designers/developers I know just don't contribute design to FOSS because interfacing with FOSS projects for anything other than bug fixes and feature implementations is often a giant PITA.

Facing critique about work we aren't confident in sucks. Most people reflexively respond with defensiveness, dismissiveness, or just shut down and ignore it. Since most FOSS UIs were created by people without subject matter expertise, most who make decisions about them have the expected response. It's like giving a brand new developer a code review. Calmly explaining how to practically reason about algorithmic complexity won't stop many from insisting a thrice-embedded loop with database calls that gets called every time an event loop runs is the best possible solution— at least for a while. Sometimes you can argue them out of it. Sometimes you just have to say "trust me— it might not matter in your dev environment, but this is fundamentally broken and needs to change."

That doesn't work with FOSS projects, and even getting to that point in the design phase takes a significant amount of work!

Even at work where a project leader is assigning tasks based on quantifiable business needs, dev teams often see design as superfluous. Most FOSS projects don't have that level of oversight. Fighting glib, dismissive, patronizing arguments born from assumptions and egos of people who believe the topic is somewhere from back-burner importance to superfluous just isn't worth it. I'm certainly not going to spend a bunch of time logically analyzing user goals and figuring out the most logical paths and visual cues to help them achieve those goals when I have to fight through that to even start coding.

Sometimes a polished user flow really is superfluous— anyone who sets up procmail enough to care about its usability will soon learn their way past its inscrutable configuration. But most applications aren't like procmail, and most FOSS interfaces aren't sufficient for their purposes. It's sad to see commercial software consistently trounce functionally identical or superior FOSS because of usability. Word of mouth + free could trump damn near any marketing/advertising campaign if people actually liked using it.


> It's a lot of work to put into something that will just get bikeshedded into oblivion by people emotionally attached to a bad ui.

How does a maintainer like me who isn't a domain expert tell the difference between:

1. A submission created by a domain specialist

2. A submission created by someone who became "emotionally attached to a bad ui" change/feature

?


Firstly, a developer emotionally attached to a bad UI is not likely to propose significant enough of a change in your interface for this to concern you.

Secondly, how would you, as a maintainer, vet a code change outside your best-known languages or paradigms? For that matter, how do you choose a mechanic if you're not a mechanic? How do you choose a caterer if you're not a chef?

Solicit outside evaluation assistance by asking for experienced design input on your repo page, newsletter, or other community gathering place. Look at previous work. Ask for portfolio links if you wish. Ask well-thought-out questions about: paths to accomplish tasks in the new vs the current setup; why specific changes are beneficial, to whom, and if it's deleterious to others; larger user goals or user groups seemingly left behind; important assumptions you think they made, fundamental implementation concerns without getting bogged down in inertia, etc. Experienced designers are used to having their work challenged and critiqued— that's true even for fresh college grads if they came from a design school.

Bikeshedding, overt dismissiveness, unnecessary defensiveness, tangentially-related gotcha questions to make the asker feel less insecure about not being the expert, and other defensive/ avoidant behaviors look the same without code involved. If you see your community engaging in them, politely ask them to change their tune or butt out. You'd do the same if a designer on your team started an ill-informed group dart-throwing session at someone sharing a technical proof-of-concept. If the person challenging the designer can't justify their assertion as well or better, you should consider if they're someone you should trust with that decision.

Thirdly, if you have to ask then it's probably never been a concern. Design is a communication field. Their proposal should be in plain language, logical, entirely justifiable, and almost certainly conceptual rather than in code. If they submit a cold PR out of nowhere with a significant interface modification and little to no justification, I wouldn't consider them a domain specialist regardless of what their portfolio looked like.

If you've got some detailed interface modification proposals you're just not sure about, a good


> Firstly, a developer emotionally attached to a bad UI is not likely to propose significant enough of a change in your interface for this to concern you.

a) They have, b) it's definitely not rare, and c) it is an enormous time-drain and source of frustration for maintainers in the FOSS community. Such devs will simply feign expertise at every turn and choose to die on the hill of their submission. In fact my previous run-in with such a dev nearly burned me out on FOSS development altogether.

> Their proposal should be in plain language, logical, entirely justifiable, and almost certainly conceptual rather than in code.

It's difficult to exaggerate how much I'd welcome such a submission! In fact I have never read such a proposal in any issue tracker, including my own. Do you have a link to an extant example, preferably one that got implemented? I honestly don't care if it's FOSS or not, I just want to read the communication back and forth.


You've never seen a thorough design proposal?

Typical commercial pre-wireframe research and proposal: https://web.stanford.edu/~eadolfo/cis-redesign/attachments/p...

More common in FOSS: https://github.com/openstreetmap/iD/issues/759 https://github.com/stashapp/stash/issues/1549 https://github.com/newrelic/nr1-groundskeeper/issues/3 https://github.com/creativecommons/creativecommons.github.io... https://github.com/godotengine/godot-proposals/issues/1823

(from google searching for things like site:github.com "wireframes" "design" "proposal")

> a) They have, b) it's definitely not rare, and c) it is an enormous time-drain and source of frustration for maintainers in the FOSS community.

I can't claim to be omniscient but I've been a constant open source contributor for 10 odd years and heavy user for nearly 25 and I've never seen that, or even heard people complain about it, let alone enough to be an enormous problem. I've seen ill-conceived gripe lists, superficial 'lets make this look cool,' and 'this font sucks' type issues periodically. None of those are serious design proposals any more than "make everything faster" or "I hate when your program does x" or "I think we should get rid of this and make it in react" are serious development proposals.

I'll happily put together a guide on cutting through bullshit UI change proposals if I could evaluate some issues/PRs for open source repos that constantly experience this problem.


>The Nielsen Norman group has some good stuff on usability within hierarchical organizations

Can you give a link?


Way too many to enumerate, but this is a good start:

https://www.nngroup.com/articles/ux-maturity-stage-1/


> I challenge every defender of that GTK/QT crap to build a swipeable sidebar into their native and responsive UI. If it takes more than 10 minutes, you lost, cause that's what it takes to use CSS, even without any IDE or toolkit.

You get this for free with Qt's QML Drawer type, and it's also a declarative UI, so you don't have to implement anything yourself[1]. It's swipeable by default.

You also get it for free with Flutter's NavDrawer.

[1] https://doc.qt.io/qt-5/qtquickcontrols-sidepanel-example.htm...


Not to be pedantic, but I'm fairly sure it's also "for free" with GTK2/3's "stack" dialogue. Don't think it's still the case with GTK4 though, I'm pretty sure all that gesture functionality was broken out into a separate library...


Yeah, I'm not familiar enough with modern GTK to speak on its behalf.


> though where the pinephone really - really - shines is pentesting.

Its worth having some near field communication pentesting apps on it, as many mental health hospitals use NFC bracelets for locking people up and to control what corridors they can get access to within the building so it could be an easy way to walk out of those sorts of establishments where lock and key are no longer used.

https://en.wikipedia.org/wiki/Near-field_communication#Criti... https://resources.infosecinstitute.com/topic/near-field-comm...


Pinephone doesn't have built-in NFC hardware and while an NFC back-cover was talked about in 2020, nothing available yet.

So one would have to either DIY something through the pogo pins or go over USB as of now.


> I still hope that webkit, javascriptcore and nodejs can be combined into something that allows to easily call C-ABI compatible libraries without 300MB of build size like electron.

Have you seen Tauri?

(Happy user, for a couple of side tinkerings, not otherwise affiliated.)


Yeah I've seen tauri, but they're just using the glib bindings for webkit-gtk. So they're just sharing the preinstalled browser for rendering inside a webview.

My goal, compared to tauri (or webview/webview), is to offer an alternative, slimmed-down version that can be used to bundle apps on mobile and embedded devices. I mean, from a security point of view you have to assume that Edge and Chrome are compromised, so all your tauri apps will be compromised too.

So in retrokit I removed things like the massive plugin legacy in webkit, or pdfkit integrations and other stuff that was unnecessary, or webgl, or canvas, or the static geolocation API (which comes with a static copy of the ip<>geolocation database) etc.


> I still hope that webkit, javascriptcore and nodejs can be combined into something that allows to easily call C-ABI compatible libraries without 300MB of build size like electron. [1]

Build it




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: