Yeah the infringement (in this old school model) would be if you then used that image as -- say -- the cover of a book or something. Then, it would be analyzed to see if it's "fair use" (satire, etc) or infringement.
I guess the question with MJ is -- if I make such a Garfield with MJ, show it to my parents etc., put it on the fridge, is that a problem? prob not. i'm not a lawyer but -- that doesn't seem like I'm infringing. but... did MJ infringe by selling me a subscription that gave me that image for pay? (pay that otherwise Garfield's IP owners might've received)
I expect this to be a something-burger but not even close to a Napster-level extinction event for AI. With gen AI, the use is not a surrogate for the copyrighted work (a replicated image of Toy Story is not like you're getting the whole film for free).
However, there is money involved so... I predict a small bump in the road of sorts
Yeah but one of the points the article makes is that people don't necessarily know if they're infringing or not with Midjourney, especially when text is generated. Only rarely if at all does this happen with humans (the subconscious is a mysterious place) but it is easy with LLMs and harder to detect because the person doing the generation is not as involved in the creation of the text. Of course LLMs could be patched to detect and alert but... how? and what incentive to do so?
Of course the models don't infringe but perhaps the people building them did by basing their IP on other people's IP. for the courts to decide...
I did a lot of design-to-developer handoff with InVision back in the day. It was great, perhaps you missed it.
Before Figma multiplayer, it was a great way to formalize the handoff, starting from Sketch, structuring everything, selecting some boards, and then using Craft (I believe it was called) to upload things to InVision, and then have more discussion there.
The devs never saw design files, just these cleanly structured handoffs. We could have conversations over details, etc. Worked well for the teams I was on.
Now the constant sync'ing was a hassle, not as fluid as Figma but it was a lot more formalized then Figma where devs are always asking "is this ready to review". I didn't explore prototyping very much, which IMO is still a big unsolved problem for the industry.
So, from me, cheers to InVision, yes times changed, sad they couldn't be a part of it, but their product was very awesome for me back in the day. PLUS, they had such a beautiful beautiful UI for their design exploration tool, everything was lightweight and contextual, it continues to inspire me to this day.
Nice share! And glad to hear your good spirits about our debate, seems not every thread is subject to Godwin's law
I agree with you -- a complete rethinking -- I've actually spent the past couple years thinking a lot a lot a lot about this. And it seems that it's not just a matter of a better design tool, but also a way of how design works in relation to code, and perhaps how the code itself changes!
Sometimes I think that Design Systems, which feel like they came from the design side of the divide, actually was a motion that started with engineering. All the componentization of React etc under the hood really powered the process where designers make components. Before that it was more typical for designers to provide these 1-page sheets with the colors, margins, etc that were more like a style guide than a system. And perhaps the strict component-based approach is part of what's throwing us into the pit of despair from time to time.
Nah nah gotta disagree (well I heartily agree with the basic characterization vertical vs horizontal here) but disagree that designers have not historically done both.
A magazine has multiple pages, views, etc., some with repeating elements. This craft has been honed for the past 100+ years. Read Bringhurst (The Elements of Typographic Style) and you'll see that book design has had both for even longer. Systematic thinking is part of any design education. Can't make a brand's various treatments congeal into a solid brand without it.
In 20th century print design, the grid emerged as a way for designers to systematize their work. And there's something interesting about working with the grid which is extremely relevant for design systems. Here's the thing -- the grid doesn't quite work.
Most designers know that, when you set up a grid, you end up making all these exceptions to make things actually look good. The one most people encounter first this issue: what happens when you put your text in a colored box? If the colored box aligns with the grid, the text doesn't (and vice versa). So people are like ¯\_(ツ)_/¯ and let one of the rules slide. And this kind of thing keeps happening as you work on a big design.
Curiously enough, the best way to see this viscerally is to read the bible on the grid in design -- Grid Systems by Müller-Brockmann. The grid is followed religiously and the book's design is stilted as a result.
Anyway in apps we have the same problem. We have a design system say in Figma. We try to design with it. We find.... exceptions. But we try to make it all work within the system. When we turn to building the app, there are yet more exceptions.
And we've all seen this in the code. These pristine components, over time, get filled with more and more little switches and settings, to gracefully handle the exceptions. And then someone comes around and says "let's refactor all of this", it ends up being quite bulky.
It seems we've reached "peak design systems", they are widely adopted, we love the benefits but are seeing hard limitations and perhaps it's time for the pendulum to swing another direction.
Designers feel more and more limited by working with a DS. They can't make exceptions so their work ends up being stilted. Or they expand the DS (requiring meetings). On the code level, there are more and more variations to manage, and also the exceptions that design-oriented devs add. Things get to be a mess. And the managers are saying "where's the ROI" so we spend time developing tools to measure DS ROI.
And so we apply more and more process, organization, more meetings, and more documentation, to make the design system work. It all gets kinda bureaucratic, against the spirit of agile. And the kicker is, the design isn't necessarily better as a result.
And so even though I kinda disagree I also agree when you say a design system should not be a thing. We treat it as a thing, try to force it to be an artifact, but it's not healthy for the set of design choices to be forced into this kind of form.
Very interesting, great to see a fresh take on what a design tool can be! For some reason I'm not hearing any audio when I play the video on noya.io on Chrome/MacOS.
This convo reminds me of MDX -- https://mdxjs.com/ -- allows you to mix JSX with markdown, popular for making documentation pages for design systems.
A lot of the limitations of MD mentioned here are alleviated by allowing arbitrary JSX, which of course is optional for users who want something more basic.
What looks intentional to one observer may seem accidental to another. “A lot of animal-behavior analysts would look at the same sequence of behavior and give a different interpretation,”