layout: post title: Sharing iTunes and iPhoto libraries between users created: 1069209960 categories:

• iTunes
• iPhoto
• sharing
• Mac
• iPhoto
• iTunes
• sharing
• file upload
• YouSendIt
• Mac
• file upload
• iPhoto
• iTunes
• sharing
• YouSendIt
• Mac
• file upload
• iPhoto
• iTunes
• sharing
• YouSendIt
• Mac

Problem: You want all users on your machine to share an iTunes and iPhoto library

Using just the Finder and some aliases, this is fairly easily accomplished.

Sharing iTunes

For iTunes, this is relatively simple. Make sure iTunes is closed. Now, move your existing iTunes folder (the one you want to share — located at /Users/[username]/Music/iTunes) to /Users/Shared.

Select the iTunes folder that is in the Shared location and Get Info (Command-I) on it. In the Ownership & Permissions section, change everything to Read & Write, and click “Apply to enclosed items”.

Next, make an alias of the folder, move it back to your ~/Music folder, and remove the “alias” string from the name. Repeat this step for all users that you want to have access to this shared library. You will need to delete their existing iTunes folder (which should be empty — move or do a file upload of any music to the Shared folder).

Sharing iPhoto

You can follow the same process as for the iTunes library, only the folder is called iPhoto Library and is located in the ~/Pictures folder.

However, this does not completely work. The link listed under resources describes modifying iPhoto to change permission settings, but it does not work completely either: both users may view all the photos, but there are permission errors related to importing images.

A comment on the Mac OS X Hints article suggests running a cron job to reset permissions. This would work, but isn’t a very elegant solution.

Resources

• Share iPhoto Libraries: MacOSXHints
• How to share… (Doug’s AppleScripts, Paul Withey): This is a much longer, more detailed description of essentially the same thing — it seems to work perfectly under 10.2, but for Panther (as I mention above) importing by both users has permissions problems

layout: post title: "asterisk*: Don’t Blame The Users" created: 1080575028 categories:

• Web Development

Blaming the users for anything should raise a huge red flag that you’ve got some usability problems. asterisk*: Don’t Blame The Users

• [[flancian]] https://twitter.com/flancian/status/1437098311954149383 pull

Authored By:: [[P- Rob Haisfield]]

Text does not need to be people’s interface for editing code. Structural editors like Fructure can make it impossible to write code that doesn’t work. Based on the function you are writing, it will suggest valid arguments to you. Advanced, context-aware autocomplete can perform the same job.

{{< youtube CnbVCNIh1NA >}}

Spreadsheets make CSVs more approachable. Airtable makes relational databases approachable. The issue with text on its own is often that it requires users to memorize a syntax, and that scares people.

Computing and craft among the end users§

Users develop craft — incredibly complicated folk-ontologies, rituals, procedures, and heuristics — for working with whatever tools they…

Computing and craft among the end users§

Users develop craft — incredibly complicated folk-ontologies, rituals, procedures, and heuristics — for working with whatever tools they regularly use, & this craft is itself a tool. A user who identifies as ‘non-technical’ is in fact extremely technical: their desire to stay roughly within the bounds of the craft they have already developed leads them to invent incredible workarounds.

For instance, my father once was required to take a short course on Microsoft Publisher 2003. He now still does everything in Microsoft Publisher 2003, including an enormous website I help him run. His familiarity with Microsoft Publisher 2003 is deeper than many professional Java programmers’ familiarity with Java, although there are large sets of features he’s totally unaware of. Almost none of that familiarity translates to Publisher 2007.

When it comes to this kind of craft, there’s a mutual legibility problem. Programmers tend to like to extend themselves to totally new environments, so the justification for making an ugly hack in excel rather than learning R is sort of alien (though we all have encountered situations where the obvious right way to do something seems like it will require so much research that we would prefer a hack). And, on the other side, because the folk ontology of users is based on empirical experience with user interfaces that go out of their way to make internal behavior inaccessible (to ‘hide’ rather than ‘tuck away’), the concepts and terminology used by programmers is meaningfully different than those used by users (and users cannot, largely, communicate among themselves about this either).

Nevertheless, craft is highly effective. That’s its primary attribute. End users get things done by inventing a superstructure that keeps their existing knowledge valuable.

[When I call for more flexible UIs with more programming-language-like expressive power](https://hackernoon.com/against-ui- standardization-791b8bbc4fbe?source=friends_link&sk=b43ce8feac13d3d6b5edfa0cb12dcd9b), I am not suggesting that all end users should go learn C or something. I’m suggesting, instead, that we should design interfaces so that when users try to apply their existing familiarity with a system to problems on the fringes of the application’s use case, they find themselves working with something more generalizable.

With applications that are too opinionated, using them outside the happy path requires identifying glitches. In more flexible applications, the outer fringe of possibility exposes the underlying language. (Think of speedrunning versus modding.) In the latter case, there is a smooth path from user to developer — and users can turn around as soon as they’ve gotten the features they need.

If we go all-in on this flexibility (as I am trying to do with [my experimental environment Kamui](https://hackernoon.com/some-tentative- guidelines-for-gui-composability-2900abead1d9)), what do we lose? Scalability (because applications quickly become customized by users to meet their specific needs and habits), top-down legibility (because those customizations are done by people without formal training, who lack the terminology and idioms of computer science), and proprietariness (since there is no core that will not eventually be touched).

I make [the big computing vs small computing distinction](https://hackernoon.com/big-and-small- computing-73dc49901b9a?source=friends_link&sk=cfdd83b23f4e703a6a5b6b2e2cdebedd) primarily based on whether or not, for some particular function, scale & legibility is more important than flexibility and extensibility. If flexibility is more important, we are in a small computing context. I firmly believe that big computing contexts are rare & can be minimized even further, with care and foresight.

By John Ohno on November 14, 2018.

[Canonical link](https://medium.com/@enkiv2/computing-and-craft-among-the-end- users-bc9a0ba8c99e)

Exported from Medium on September 18, 2020.

Briefly - plugin ecosystems are awesome for end-users insofar as it allows users to create features that the core developers don’t have time for. However, the plugin developers will often do this out of the goodness of their heart or out of a personal need for a specific plugin, leaving many users dry, especially if a plugin developer loses the energy or will to maintain the plugin over time. A plugin marketplace is an obvious answer, but this needs to be balanced against a desire not to prevent the community vibes coming from an intrinsically motivated system.

Why use the word Stakeholder§

• Stakeholder is less conceptually limiting
• Stakeholder includes people who have an interest but might be otherwise missed
• User can come across as demeaning or subjectifying
• You need to consider externalities, and broadening your thought process helps with that
• Users have a stake in what you’re doing
• Elevating others is inherently good for your brand and for society

This page is art of the [[Feminist Chatbot Main Page]].

TPM is rarely used to protect users§

[[TPM]] is rarely used to protect users.

While TPM has legitimate uses and could theoretically benefit user security if handled through free software, it is overwhelmingly used not to protect its actual users, but media conglomerates. Today, most of the major streaming media platforms utilize the TPM to decrypt media streams, forcefully placing the decryption out of the user’s control. Why then require a TPM? It’s easy: by offloading the decryption to a separate piece of hardware running its own software, media companies can ensure that users won’t try to access the files streaming through their own machines.

– IDAD 2024 - Dec. 20: For freedom, against restriction | Defective by Design

See: [[TPM is used overwhelmingly to protect media conglomerates]]. This is what TPM is actually used for.