11 Matching Annotations
  1. Jun 2020
    1. News can no longer be (only) about the mass update. Stories need to be targeted to those who might be able to improve the situation. And journalism’s products — which are more than its stories — must be designed to facilitate this. News needs to be built to engage curiosity about the world and the problems in it — and their solutions. People need to get lost in the news like they now get lost in Wikipedia and Facebook. There must be comprehensive stories that get the interested but uninformed up to speed quickly. Search and navigation must be improved to the point where satisfaction of curiosity is so easy it becomes a reflex. Destination news sites need to be more extensively hyperlinked than almost anything else (and not just insincere internal links for SEO, but links that are actually useful for the user.) The news experience needs to become intensely personal. It must be easy for users to find and follow exactly their interests, no matter how arcane. Journalists need to get proficient at finding and engaging the audience for each story. And all of this has to work across all modes of delivery, so it’s always with us. Marketers understand this; it’s amazing to me that the news industry has been so slow to catch on to multi-modal engagement.

      everything would work perfectly if we had all of these and people are actually rational and diligent with infinite resource.

    1. you could say the same thing about a lot of new productivity apps as well - they’re trying to capture something intangible about the way we work, collaborate, share and organise. Now that we’re all locked down, half the software engineers on earth are sitting at their computers swearing at their tools and thinking of new ways to collaborate, with video, text, voice, screen sharing, or something else again, and with synchronous or asynchronous models, or something else. But the interesting ones here aren’t just ‘video’, or ‘screen sharing’ or ‘notes’ - they’re bets on how to present that differently, and to work differently. They’re bets on psychology and on how people might feel about working that way.
    1. For me the best part of Upcoming was being able to see what events my friends are going to. With their redesign, Upcoming decided to hide that behind two clicks. Now when you go to the site, I see whats popular in San Francisco, but I have to click to see what my friends are upto. Even on an events page, I can no longer easily see if any of my friends are going there. Instead I am shown the groups and tags. But I have to click to see who is attending.

      tiny changes to the UX. not understanding the JTBD of your product

    1. I kind of wish there was an HN like job site that was widely used in corporate America but didn’t have all the ‘content’. Just an online resume

      wondering what's the original purpose of adding the news feed to LI, the product decision.

      lack of understanding I think. to drive "engagements" and keep eyeballs? what's the incentives and how do they relate to LI's biz model?

  2. May 2020
  3. Aug 2017
    1. Research debt is the accumulation of missing interpretive labor. It’s extremely natural for young ideas to go through a stage of debt, like early prototypes in engineering. The problem is that we often stop at that point. Young ideas aren’t ending points for us to put in a paper and abandon. When we let things stop there the debt piles up. It becomes harder to understand and build on each other’s work and the field fragments.
  4. Mar 2017
    1. Now that you have your component hierarchy, it's time to implement your app. The easiest way is to build a version that takes your data model and renders the UI but has no interactivity. It's best to decouple these processes because building a static version requires a lot of typing and no thinking, and adding interactivity requires a lot of thinking and not a lot of typing.
    2. You can build top-down or bottom-up. That is, you can either start with building the components higher up in the hierarchy (i.e. starting with FilterableProductTable) or with the ones lower in it (ProductRow). In simpler examples, it's usually easier to go top-down, and on larger projects, it's easier to go bottom-up and write tests as you build.
    3. To build a static version of your app that renders your data model, you'll want to build components that reuse other components and pass data using props. props are a way of passing data from parent to child. If you're familiar with the concept of state, don't use state at all to build this static version. State is reserved only for interactivity, that is, data that changes over time.
    4. Since you're often displaying a JSON data model to a user, you'll find that if your model was built correctly, your UI (and therefore your component structure) will map nicely. That's because UI and data models tend to adhere to the same information architecture, which means the work of separating your UI into components is often trivial. Just break it up into components that represent exactly one piece of your data model.