TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Developer Experience: Fundamentally harder than normal UX

114 点作者 werg大约 5 年前

22 条评论

Glench大约 5 年前
To make some of the ideas in this article a little more concrete, here are some research demos I’ve made:<p>* Legible Mathematics, an essay about the UI design of understandable arithmetic: <a href="http:&#x2F;&#x2F;glench.com&#x2F;LegibleMathematics&#x2F;" rel="nofollow">http:&#x2F;&#x2F;glench.com&#x2F;LegibleMathematics&#x2F;</a><p>* FuzzySet: interactive documentation of a JS library, which has helped fix real bugs: <a href="http:&#x2F;&#x2F;glench.github.io&#x2F;fuzzyset.js&#x2F;ui&#x2F;" rel="nofollow">http:&#x2F;&#x2F;glench.github.io&#x2F;fuzzyset.js&#x2F;ui&#x2F;</a><p>* Flowsheets V2: a prototype programming environment where you see real data as you program instead of imagining it in your head: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=y1Ca5czOY7Q" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=y1Ca5czOY7Q</a><p>* REPLugger: a live REPL + debugger designed for getting immediate feedback when working in large programs: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=F8p5bj01UWk" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=F8p5bj01UWk</a><p>* Marilyn Maloney: an interactive explanation of a program designed so that even children could easily understand how it works: <a href="http:&#x2F;&#x2F;glench.com&#x2F;MarilynMaloney&#x2F;" rel="nofollow">http:&#x2F;&#x2F;glench.com&#x2F;MarilynMaloney&#x2F;</a>
评论 #22406361 未加载
评论 #22406656 未加载
评论 #22405956 未加载
评论 #22405507 未加载
kurnikas大约 5 年前
&gt; We&#x27;ve simply gotten used to them: Dealing with the idiosyncracies of bash, vi, or the JavaScript type system<p>This stuck out to me, there seems to be a trend in UX&#x2F;UI where any move away from the &quot;simplest path&quot; is seen as a huge negative. Could it be the case that we use these tools (especially UI patterns like vi) because after the learning curve the give a huge amount of value? It seems like we are assuming that we should make a developer tool with the same level of &quot;immediate familliarity&quot; that we try to build into a website where customers will bounce easily, for an audience who is willing to spend time learning a tool if it provides value to them.
评论 #22403296 未加载
评论 #22403022 未加载
评论 #22403683 未加载
评论 #22402895 未加载
评论 #22403884 未加载
评论 #22402935 未加载
评论 #22403394 未加载
评论 #22405328 未加载
评论 #22402891 未加载
评论 #22405586 未加载
评论 #22405587 未加载
alxlaz大约 5 年前
Far from me to defend every UI of every development tool out there but I think statements like these, and their illustration, could benefit from some explanation for those of us who are not designers:<p>&gt; We coders still put up with horrid UX&#x2F;UI when programming.<p>which is illustrated with a screenshot from Visual Studio... .NET 2002, I think, judging by the application icon?<p>Setting aside the relevance of a 20-year old screenshot, what exactly is wrong with that interface and what makes it horrid? I mean it definitely had its quirks but:<p>- It&#x27;s spectacularly compact, certainly way better than anything I&#x27;ve seen in the last five years. We could display an UI builder and the associated code on single 1024x768 screen and work on it semi-comfortably. &quot;Beautiful&quot; UI&#x2F;UX, as understood today, is so cluttered by whitespace (oh, the irony...) that it&#x27;s barely usable on a 1920x1080 screen. A similarly compact interface on today&#x27;s huge screens would be a dramatic productivity improvement that, twenty years ago, we could only dream of.<p>- You could easily access any function through textual menus -- no hamburger menus, no obscure, monochrome icons. Granted, the toolbar icons were a pain, but the way I remember it, most of us either disabled it straight away, or just populated with a couple of items that were of real value and which we knew well.<p>- The colors have great contrast, the whole thing is readable even on a very poor-quality screenshot that seems to have been actually downsized.<p>- UI items have enough relief and&#x2F;or distinction that it&#x27;s clear what you can interact with and what you can&#x27;t (maybe the item palette from the diagram editor is an exception, or at least the screenshot makes it look like one, but virtually every program in that era made it look like that so it wasn&#x27;t so hard to use).<p>So what&#x27;s wrong with that thing?
评论 #22404608 未加载
z3t4大约 5 年前
The problem with developer tools is not technical, it&#x27;s all about the selling part. If you make a new superior developer experience, you think developers will instantly see the benefits? haha! You first have to teach them, then after a few month if you are lucky you will get a &quot;aha, now I understand&quot;. So first you need to manually educate each user until you have a critical mass. Then you need to market and hype your product. So that developers will tell each other how cool your new technology is. Continue with that a few years until there are code in production that use your product, before even thinking about a business plan. So there are few options, either you have enough money so that you do not have to &quot;work&quot; again, and can spend your time making new tools. Or your current employer lets you work on the tools. For a startup working on developer experience (language and tools) I would suggest a 10 year runway (funding) and that 1&#x2F;3 of the budget goes into educating users and 1&#x2F;3 goes to marketing.<p>Any software business that is profitable, already have code in production, and that code need to be maintained. So instead of creating a new better experience, you can make the current experience better. eg. putting rockets on a horse, rather then creating an automobile.
评论 #22403256 未加载
评论 #22403367 未加载
hinkley大约 5 年前
I told my UX buddy half a dozen years ago that I was optimistic that there seemed to be a glut of UX people coming because we were going to steal a bunch of them to look at DevEx issues.<p>I spent some time nerding out over woodworking hand tools a few years back and it pretty well cemented for me something that I’ve suspected for most of my career: people down in the muck have very limited vision. That your output is only better than your input by degrees.<p>I’m not sure there would be much fine woodworking at all if the best woodworking tools were only as good as the best software tools. There is no Lee Valley of developer tools. You can’t make me stop using JetBrains (individual licenses were their best idea every), but it still doesn’t rate above a Woodriver, and if I’m honest some of their stuff is Stanley level, and not even the antique stuff. And their stuff is better than just about any other tool I use all day.<p>I suspect Harbor Freight could make better software than Atlassian, and I don’t even mean that as a metaphor. I think I could take harbor freight employees and get better requirements out of them because they wouldn’t be up to their ears in cognitive dissonance.
评论 #22405868 未加载
grahamlee大约 5 年前
I don&#x27;t think that DX is harder than UX because developers somehow have a more complex task than everybody else, and that there&#x27;s therefore a richer &quot;experience&quot; to navigate than in other domains. I think it&#x27;s because developers tend to be developers, so are more aware of and willing to accept the nuances and complexities that go into development. In other words, we&#x27;ve got a more detailed understanding of the developer experience because, as developers, it&#x27;s what we experience.<p>We accept the heritage of developer tools - the keyboard-driven interface that displays to a teletype emulator, the edit-compile-debug workflow - and build tools that improve the processes that have built around those legacies. This is why when something comes out of left field like Adele Goldberg and colleagues describing Smalltalk, we find it easy to adopt the approach to code organisation on offer and hard to adopt the image model, browser-based workflow, debugger-driven iteration, and other changes.<p>Meanwhile, when we go out into other domains, we use a little bit of understanding of that domain, a lot of reasoning by analogy, and an intention to &quot;disrupt&quot; what already exists and &quot;eat the world&quot;, and create something that works very well for the spherical user in a vacuum without all of the detailed understanding that comes from having grown up in the system and learnt from people who grew up in it even longer ago.
评论 #22404067 未加载
评论 #22402987 未加载
jussij大约 5 年前
&gt; There has been tremendous growth in the field of UX&#x2F;UI. Without a doubt, today&#x27;s applications are much more user-friendly than those from 30 years ago. Back then, users were given features, interface be damned.<p>That 30 year time frame takes us back to 1990 and back then the user experience was limited by the technology of the time.<p>However a decade later we had Windows XP.<p>I would say that 20 year old Windows XP might in fact be a much better user experience than the modern UX&#x2F;UI we have to live with today.<p>The much less powered CPUs of that time felt much more responsive than the modern day CPUs&#x2F;OS that we have to today.
pjc50大约 5 年前
&gt; How do I run this thing? Where does the code start? Is my system configured correctly?<p>This is why there are occasional spasms of &quot;back to basics&quot; or plaintive remembering of the BBC Micro. You power it on, it beeps, and within a second you&#x27;re in the interactive development environment. Typing code runs it directly. Typing code with a line number adds it to the program. No configuration, containers, downloads, updates, dependencies or uninformed choices to make.<p>&gt; Why do we treat this as a moral failing instead of a usability issue?<p>Yes. This applies in so many places. Learn from &quot;Poka-yoke&quot;. The system should make it easier to do safe things and harder to do unsafe things.<p>&gt; Tests are a usability dead end<p>Depends what you mean by &quot;tests&quot;. A strong type system does away with certain categories of test (and conversely a lot of the heavy unit testing usage comes from communities with weakly typechecked languages). But both types and tests are capturing a human-level requirement of &quot;if X then Y&quot;, a constraining of the problem space.<p>This is why many successful code archaeology maintenance projects start by building a test suite to capture the current functionality of the program. An executable requirements document.
quelltext大约 5 年前
&gt; Tests are a usability dead end -- I know this may be contentious, but I believe test suites are another realm of excessive moralizing en lieu of better tools and better processes. Too often they function as a security blanket that simply encases the parts of the code that are unit testable, while leaving the vulnerable, untestable bits fluttering in the wind. Approaches such as generative testing seem more promising.<p>I&#x27;m not quite sure what the author is arguing for here in particular.<p>Anything that makes writing tests a bit easier, e.g. suggestions for additional test cases, would be cool, but ultimately tests are about writing down your assumptions&#x2F;expectations about the code.<p>No, they are not formal proofs and sometimes they are not perfect but they still provide a lot of value. So far I haven&#x27;t found a good reason not to write tests (since I outgrew my newcomer attitude) and yeah integration tests are usually what I focus on most. For any case where testing whole systems today is hard, there are some fundamental challenges (e.g. end to end web UI test). I don&#x27;t quite see how tooling will get rid of the need for tests.
评论 #22402928 未加载
Gehinnn大约 5 年前
I think that improving DX might be the most important thing of the future software industry. If a single developer devotes his live to a better DX, hundred of thousands of developers might be significantly more productive.<p>I really like to explore new DX approaches (just recently, I published an extension for VS Code enabling visual debugging [1]). But I find it hard to make a living out of it, as so many companies find it granted that everything is free. They would rather hire another developer than paying for licenses that might effectively increase the effiencency of the developers they already have.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;hediet&#x2F;vscode-debug-visualizer&#x2F;blob&#x2F;master&#x2F;extension&#x2F;README.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;hediet&#x2F;vscode-debug-visualizer&#x2F;blob&#x2F;maste...</a>
评论 #22404615 未加载
评论 #22406044 未加载
wruza大约 5 年前
This. Despite latest &lt;libname&gt;-cli trend, anything slightly more sophisticated requires to create a structure, then create structures in nodes, then a configuration structure, structures all the way down. One could object that everything we do is structures, but there is no ui to these, only a <i>text</i> file and a formal documentation (if you’re lucky).<p>Text files and their disconnection from a documentation is a root of all our evils. Not only they diverge with new versions of everything, but there is a constant attention switch (stacks of them!) and unnecessary diving into things that may or may not be important to the development process. There is no way to omit these checks when you learn or return to an idle project.<p>I have a long time idea that every config, format, api call, and so on should come with inseparable documentation ui (+rationale, examples of use, best practice links, pre-configuration, diff&#x2F;merge views, etc). Yes texts are simple and easy to read, but we also write. You can make text from a structure in O(1), but you cannot make a knowledge from an empty file in O(sensible), for any sensible sensible.<p>Not arguing on salaries though. Even pretenders who have no clue can take a great cut off this nonsense.
评论 #22403201 未加载
评论 #22403926 未加载
edent大约 5 年前
I taught Scratch to kids. They love the visual element of the language. It&#x27;s so hard to make basic mistakes - partly because you <i>can&#x27;t</i> put an Int where the code expects a Bool.<p>The interface shows you all the components you can use, and what data they require.<p>I then move on to teaching Python, and watch kids get frustrated.<p>Languages like DRAKON should be the future of our profession - not typing 80 char lines into a terminal.
评论 #22405938 未加载
karatestomp大约 5 年前
The other day I was using MusicBrainz Picard and it occurred to me just how absolutely pleasant it is. It uses standard desktop widgets, is fast, has some nice attention to detail and consistently accurately relates the state of things, is powerful, and stays out of your way. It—and this is #1-with-a-bullet more important than every other UX concern—behaves consistently.<p>I don’t think it would survive a pass from most “UX” folks in such a nice state. It 1000% wouldn’t survive a designer or hybrid designer&#x2F;UX person (it wouldn’t look pretty in screenshots on their portfolio).<p>The main problems in software tools are lack of consistent behavior, lies, and tons of ways to use a bunch of tools that all do basically the same thing (and you’ll probably have to know more than one). The hardest part’s not using them, exactly, it’s knowing all the different, stupid reasons they break. It’s a general quality issue more than a broader UX thing, I think. That extends to libraries. And I don’t <i>also</i> mean tools and libs from big names—I <i>mostly</i> mean them.
koffiezet大约 5 年前
A site about UX that uses a fixed-sized font with horrible spacing? This I about the worst website UX I can imagine... Long live reader view...
评论 #22405497 未加载
dusted大约 5 年前
I can&#x27;t be the only one who prefers the way applications looked 30 years ago? When they dumped whatever they had to offer right there for you to explore and pick from. These days everything is hidden below a million layers, trying so hard &quot;not to be in your way&quot; that you need a deep love of pixel-hunt-point-and-click adventures to get anything done..<p>Let&#x27;s take an example: Specifying DNS servers in Windows. 95: 1. Rightclick &quot;Network&quot; on desktop -&gt; Properties 2. Doubleclick on the TCP&#x2F;IP protocol for the NIC. 3. Type new DNS server. 4. Press OK.<p>10: 1 Press start 2 Search for control panel 3 Open Network and Internet settings 4 Select Change Adapter Settings. 5 Rightclick NIC and select Properties 6 Select TCP&#x2F;IP and then Properties. 7 Type new Server 8 Press OK<p>Sure, some may think that Windows 10 looks better than Windows 3.11 or 95, but I don&#x27;t and I can&#x27;t believe everyone does.
yoshyosh大约 5 年前
I think developers are missing the testing practices UX designers have grown accustomed to:<p>1. Usability tests where developers literally sit down and watch someone install and use your library from scratch (I find a lot of developers do not like to do this). Things like, seeing where they have to look up documentation (and how they do it), what bugs they hit, and how often they make common mistakes. I think a lot of this could be logged e.g. A developer signs up, you have their email + API key, you can connect the dots between what doc pages they view, how often, and what errors they commonly run into.<p>2. Doing whatever it takes to minimize the time to aha moment. This is absolutely critical for any product design effort, but not many companies measure this if any at all when it comes to DX. I think Twilio and maybe Stripe are the only ones that may have had this as a key onboarding KPI.<p>Ultimately I think a majority of developers that are capable of implementing these things are quite technical and used to the general state of DX so they don&#x27;t view bad DX as much of an issue unless its really terrible.<p>Lastly, I really wish error messages would just be super informative. For example getting something like this &quot;undefined method `my_method_name&#x27; for nil:NilClass (NoMethodError)&quot; still feels a bit cryptic to someone newer to programming, if you can also tell me the human readable variable that I used that caused this issue, the one that was nil, and the exact line (the stack trace purely by itself can be confusing) that little touch would go a long way. For example compare that error message to something highlighted in a different color that says &quot;The variable you used called &quot;contact&quot; on line 87 was found to be nil, this is likely causing this issue&quot;. This way when you run into the error and are scanning the stack trace, the computer is telling you as quickly as possible what may be wrong, again for a novice since the way the original error is written for someone more experienced is likely succinct enough.
评论 #22405983 未加载
kaens大约 5 年前
&gt; When was the last time you heard of a programming language discussed in terms of discoverability, succinctness, relevance, let alone beauty?<p>I mean, fairly often throughout the years. Particularly in communities for lisps, ruby, perl, python, C. More common 5-10 years back perhaps.<p>Relevance is a fairly common topic across the board. Discoverability is maybe the least common topic here, and one that&#x27;s a pretty interesting one for PL design imo.<p>I haven&#x27;t seen too many <i>blog posts</i> about these things lately, but they&#x27;re frequent enough discussions in personal circles and in mailing lists&#x2F;chats that this question seemed odd to me.
regularfry大约 5 年前
I disagree with the premise.<p>The problems the author identifies largely <i>have already been solved</i>. The solutions just haven&#x27;t become universal, generally for reasons completely unrelated to the actual problem, and more to do with PR.
评论 #22406009 未加载
boomlinde大约 5 年前
I wouldn&#x27;t say it&#x27;s fundamentally harder. It&#x27;s fundamentally the same thing, because developers are users, and software development isn&#x27;t the only domain where users have discerning tastes and needs that they want catered to. It&#x27;s not the only domain where users will happily accept a steep learning curve for the years of use that will pay off that initial investment, or where shoving detailed information under the carpet can be a negative thing.<p>I think it would be arrogant to think of software development as exceptional in this sense, but it&#x27;s certainly reflected in a lot of software designs. The reality IMO is that if you aren&#x27;t working off a set of insights and observations like the one listed in the article—regardless of your users&#x27; domain—you aren&#x27;t making enough of an effort to design for your users.
_pmf_大约 5 年前
You think it is harder because you are not familiar with the depth of non-developer workflows. Developer hubris.
评论 #22403572 未加载
raxxorrax大约 5 年前
I wish we could scrap the term experience again and just go back to interface.<p>I connect experience with hyped concepts that are already forgotten today.<p>That said, tendency to decrease choice seems to only serve certain users. Other feel just as restricted as developers, which are also users, so the dichotomy should be questioned.
azhenley大约 5 年前
&quot;DX&quot; is indeed important. Myself and a number of other academics have been researching the topic for years.<p>See here for examples of publications in the area: <a href="http:&#x2F;&#x2F;web.eecs.utk.edu&#x2F;~azh&#x2F;publications.html" rel="nofollow">http:&#x2F;&#x2F;web.eecs.utk.edu&#x2F;~azh&#x2F;publications.html</a><p>Also relevant, I wrote a blog post for students to get started in human factors in software engineering: <a href="http:&#x2F;&#x2F;web.eecs.utk.edu&#x2F;~azh&#x2F;blog&#x2F;guidehciseresearch.html" rel="nofollow">http:&#x2F;&#x2F;web.eecs.utk.edu&#x2F;~azh&#x2F;blog&#x2F;guidehciseresearch.html</a>
评论 #22406054 未加载