small_avatar_AdrianR3.png

thumbnail_avatar_AdrianR3.png

avatar_AdrianR3.png

Adrian

GET IN TOUCH

Maintaining the consistency of the generated image - to apply it in later ones and create a coherent story - is a huge challenge for Midjourney. The puppet method is tedious and rigorous, but it allows for very satisfactory results - especially for individual characters.

The puppet method uses a very specific prompt template and allows for relatively efficient operation of a previously generated character.

The template looks like this:
![blog-_grafika1.png](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika1_f3d2858794.png)

So let's discuss all aspects one by one:

Puppet template:

**1. Character image**

**2. Background description**

**3. Character description**

**4. Description of activities – character animation**

**5. Extras – atmosphere and parameters**


You should use this template with all keywords - then they act as a reusable puppet (actor, character). You can change the setting, activity, atmosphere, media type, etc., around her to direct this character. Later, once you've mastered the template, you can experiment with removing or rearranging keywords.

![blog-_grafika2_2.png](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika2_2_d3bf85d54f.png)


The template is based on weighted phrases, strong keywords and a specific sequence. As you use it, it becomes easier and easier to modify. To complete it you need:

#### Character image

The character reference image should roughly reflect the character's appearance when Midjourney integrates it into the final scene. You can use a ready-made photo or a previously generated image—you need a link (to the image on Discord or online), which will be a model of the character. It is important that the character "fits" the scene.

If you provide a reference in the form of a cropped head-to-shoulder portrait, remember that Midjourney will have difficulty coming up with a body for the character and will likely ignore attempts to show the entire body. And if you provide an image in which the character's face is only a few pixels in size, remember that Midjourney will have a hard time coming up with a face, and the results showing the character's face may be completely different. Therefore, it is essential to roughly match the reference image to its appearance in the final image. The character image must have a simple or blank background to help Midjourney focus on the character.

**REMEMBER**! Of course, there is no guarantee that the character will look like the image provided. Reference graphics only have influence, so you won't be able to recreate an exact portrait of yourself or your loved ones, but you have a chance to get a really similar result. You can also increase the weight of the reference image using multiprompts.

##### EXAMPLE

Using the prompt: photoshoot of blue-hair pixie-cut hipster-girl, full body, white background, I generated Lizzy. The portrait below has a light background a clear face, and is cropped in half - this suits me because I don't want to create the entire silhouette and a blurred face, but rather place it in various situations in this close-up. So – this is Lizzy.

![blog-_grafika3.png](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika3_6ddc2a4210.png)

#### Background description

The background description begins with "Setting is" (case sensitive!) and can be supplemented with both text and an image. 

The important thing here is to describe the scenery as precisely as possible. These should be short, characteristic phrases that clearly define Midjourney, where our puppet is to be. We do not use verbs then - we try to provide a static description of natural circumstances. You can also use a reference image for the background - then remember that your prompt should match it - that is, describe what is actually in the scenery. 

In this case, we set the scenery to a night vision of the city and its rooftops.
![blog-_grafika4.png](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika4_11e801ffed.png)

Pretty good, right? It's definitely Lizzy - our chosen character. The last two pictures clearly show the city at night. Lizzy is reading a book, as we indicated in the prompt. Let's move it to some other, more appropriate place…
![blog-_grafika5.png](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika5_98bb9c9d66.png)

Lizzy is still reading the book - but the environment has changed. He's not on the roof anymore, just... that's right. Not very library-y, right? It was supposed to be an old-school library, but there were a few books. So, I will generate and add a background reference image:
![blog-_grafika6.png](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika6_446f10dfea.png)

Oh, a very nice bookcase, a different atmosphere of the place, so I'll add both a link and a description to the prompt:
![blog-_grafika7.png](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika7_eec74e1768.png)

And this is much closer to the effect we wanted to achieve.

The entire prompt remains unchanged—it only adds a link to the background. It is also important to maintain a similar (or preferably the same) background description—"vintage library with bookshelves"—as when generating it. If you use a ready-made photo, describing what is in it is important. The discrepancy between the reference image and its description may lead to interesting effects, but it will certainly add artefacts and weaken control over the character. 

#### Character description

The text description should always start with the Name is (case sensitive) and consist of the character's characteristic features. There is also a part here where you give the character a name - it should be as neutral as possible. If you choose the name Mulan and then create a blonde girl - you may find that she doesn't look exactly like a Swedish girl. However, remember - archetypes are on your side and choosing a super-characteristic name can also have its advantages.

But be careful! This is not the place to describe what the character does - only the most characteristic features that define him as a character. You can dress up the character and make a puppet out of him in a moment - not now. Now focus on a short and focused description

If you generated a character using Midjourney - it is worth using the description that created it. If it is long, use the /shorten command to see which keywords Midjourney considers the most important. In the examples given, I constantly use the exact description of Lizzy that I used to create her.  

####  Description of activities – character animation

A text description of a character doing something in a scene or setting must begin with Setting contains (case sensitive). Now you can "move" your puppet. But don't go crazy - the activity description should be limited to two or three elements.

It's best and easiest to change things one at a time, such as:
- character wardrobe
- character emotions
- key activity


So, in the image below, we dress Lizzy up in a scarf and jacket.
![blog-_grafika8.png](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika8_03d373620f.png)


While elements such as clothing or expressed emotions are easy to change here, and Midjourney usually has no problem, assigning the action performed is more complicated. Everything the character does should be matched to the character's reference image. Do you have a full figure? Forget biting your lip. Do you have a portrait painting? Jumping over obstacles won't be good. 

#### Extras – atmosphere and parameters

The last space is left for adding a few keywords and parameters. Try not only to maintain style but to enhance it. Notice that in the previous two examples, when Lizzy is in New York wearing a scarf and jacket - the prompt is - photo by Ann Leibowitz. I chose an emotional, well-known artist to suggest to Midjourney that I wanted a piece of street photography. In the example of escaping from a dinosaur, I added an "action movie cinematic photo" to get a dynamic image like an action scene, not a nostalgic portrait. You can also set all other parameters of the generated graphics here - version, aspect ratio, style - just like in any other.

![blog-_grafika9.png](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika9_a76f67463b.png)


BONUS TIPS

Multiprompts divide the template into appropriate sequences ending with two colons. Before you start modifying them, make sure you know the rules of multiprompts. Increasing the weight of any multiprompt sequence (background, animation, etc.) can strengthen its impact on the generated graphics.


large_blog-_cover.png

medium_blog-_cover.png

small_blog-_cover.png

thumbnail_blog-_cover.png

blog-_cover.png

Midjourney guide part 6: The puppet method

Frontend Engineering

UX/UI Design

Research & Discovery

AI For Your Business

Services

Case Studies

About us

Blog

React has been around for a while, and it is currently the leading frontend framework (ok, library). It somehow manages to stay ahead of the pack despite tough competition. The React community is massive and that in itself is a good enough reason to expect a framework to stay popular as the adoption curve cycle slowly plays out. This sort of drift, however, is definitely not what’s happening with React. In fact, React stays popular because it keeps reinventing itself in the attempt to answer the changing needs of UI engineering (and, for the most part, does so gracefully, without compromising backwards compatibility).

This article looks at React's latest attempt to chart a new course, this time by laying out a bold vision around extending the component ecosystem into the server with **React Server Components**. The technology is not yet fully production ready, but you can already test early implementations offered by Next.js (and Remix might soon follow suit), and so it is probably mature enough that decision makers in companies using React (or considering using React) should start paying attention. 

First let’s understand the challenges the React team is trying to address and then look at potential adoption challenges and how the way we build and structure teams of React developers going forwards would change should the vision be brought to fruition.


#### **Why is React evolving towards the server side?**
It may come as a surprise if you’ve worked with react for years, but the React team now recommends to start new React projects through fullstack React metaframeworks:

![ ](\uploads\blog-serverReact_post_01_7EIWdEC0ow4M5qFf65l5pA.png)
*Source: react.dev*

The emphasis on using a framework is such that they felt it necessary to preempt the question of whether React is still its own thing.

![ ](\uploads\blog-serverReact_post_02_6XqaSpCjS2vNDLNmmc5Vy2.png)
*Source: react.dev*

This is quite a shift, considering that for the longest time the recommended solution was to use CreateReactApp - a tool built by the react team which spins up a React SPA (i.e. a client side only app). **What explains that change?** In short, React Server Components. Answering this question in a bit more detail is still rather challenging though, because – while the authors know the answer very well – they’re still figuring out the best way to communicate this to the outside world in a way that would capture people’s imagination. Luckily, **Dan Abramov from the React core team has lately given us a sneak peak** of their thinking by testing some pitch ideas for React Server Components on his private twitter account.

![ ](\uploads\blog-serverReact_post_03_7Ct4KhNuhk4eZXZDX0I28K.png)
*Source: Twitter*

You can read the whole thread here:

["i need to start collecting ways to pitch react server components.](https://twitter.com/dan_abramov/status/1631885118355718144?lang=en-GB)
"

But here’s my top 3.

#### **Best pitch for Server Side Components: 3rd place**
![ ](\uploads\blog-serverReact_post_04_jsP1HQs3YXsp6dBnnm21l.png)
*Source: Twitter*

This one, Dan readily agrees, is a little hyperbolic - but then most good sales pitches are. It gets third place because it’s rather inaccurate, but it does communicate the promise of having to think about getting data as part of architecting your UI much less often. 

Currently the data fetching pattern the react team has converged on is all about favoring collocation of components and data fetching, i.e. each component knows what data it needs and fetches it as required. There are many benefits of this approach, full composability being probably the largest. The drawback is that, since all that fetching happens on the client, each component triggers its fetching logic only once it gets rendered, which depends on the ancestors having been rendered and having fetched their data etc. - a waterfall of queries ensues, and the need to cache and dedupe requests on the client presents itself very quickly as the app grows. 

In Meta (React’s mother company) that is handled by the Relay framework, which facilitates stitching together a top level GraphQL query based on data dependencies declared locally by every component. It then takes care of optimizing a single top level query, which includes deduplication (the same data requested by multiple components gets requested once). Relay is a very powerful solution, check out this talk by Robert Balicki from the React Data Team to learn more: [https://www.youtube.com/watch?v=lhVGdErZuN4](https://www.youtube.com/watch?v=lhVGdErZuN4)


While RSC and Relay are very different things and might be used in conjunction, **they do have an overlap when it comes to solving request orchestration and deduplication**, i.e. in both cases developers worry less about optimizing data fetching. 

Here’s another tweet from Dan, which sadly didn’t make it to the top three: “**read data on the server, pass it down by props**”. This means developers would essentially be able to “think in components” also on the server. With React Server Component you can simply await a promise inside a (server) react component instead of fetching from the browser. 

The best part is that you’re not limited to treating your server components as “all knowing parents” responsible for getting all the data children need (which is what route level fetching in Multiple Page Applications is). Instead, you can be as granular as you want. You might choose to place a server component at the bottom of the React tree even if it has client rendered ancestors. Hopefully this illustrates why React developers in the future might worry less about using APIs and instead focus on the best ways to combine components, each of which would handle their own fetching concerns, with the actual fetching benefiting from some optimizations higher up.


#### **Best pitch for Server Side Components: 2st place**
![ ](\uploads\blog-serverReact_post_05_6oyCT94PSinGhUFajfUJ25.png)
*Source: Twitter*

This one is the key to understanding why building server first React components sits well specifically with React. The concept of facilitating the component based UI architecture paradigm both on the frontend and the backend is not limited to React but React’s unidirectional data flow is especially well suited to play well with such a setup. 

React treats the UI primitives like they are just values. You can keep them in variables, pass them around and compose them into larger groupings that behave predictably precisely because data flows through them only one way.

![ ](\uploads\blog-serverReact_post_06_4DCvJN1QEpawIimpDTpJpr.png)
*Source: Twitter*

Subsections of the component tree get selectively rerendered as required in order to reflect changes in data. It is therefore important to control at which level of the virtual dom tree the data changes are detected and reacted to. React developers know this problem as “lifting state up”, i.e. moving a piece of data as high up as necessary (closest common ancestor), but not higher (to avoid unnecessary rerenders). 

Now thanks to React Server Components developers can design their state architecture the same way but they can now decouple the problem of component structure from the challenges of sourcing the data in a streamlined fashion. 

With RSC, what arrives in the browser is a serialized json describing the react tree with the server side components already broken down into base html tags containing the results of any data crunching that happened on the server (it also contains elements acting as placeholders for client side rendering). There is no rerender triggered by the fetched data suddenly arriving somewhere higher up in the tree. In this sense, the server data orchestration serves as the top level of the unidirectional data flow, even if the components themselves are deeply nested in the react tree structure and have client rendered ancestors. Powerful stuff.

#### **Best pitch for Server Side Components: 1st place**
![ ](\uploads\blog-serverReact_post_07_5rVtbB7A2yPrv3agQ2Dp2r.png)
*Source: Twitter*

This pitch idea hits the nail on the head, I think. It’s all about still thinking in components but extending the composability. SRC is an entry point to the future where react components can be published on NPM and have their own data fetching concerns fully met out of the box rather than having to rely on app developers to understand what data is needed. 

This is the benefit that is much more interesting to CEOs than the details of how this is actually achieved. Imagine how much more streamlined the work of large react teams becomes if components can handle their own data in a way that allows you to put them together in more complex groups without footgunning yourself. 

That vision is definitely appealing. So, what are the drawbacks and challenges we might expect should it be realized?

#### **Fullstack React: added complexity vs metaframework lock-in**
The already mentioned emergence of react meta-frameworks, i.e. frameworks built on top of React, is not a problem in itself - on the contrary - next.js, remix and other frameworks have a lot to contribute. 

That said, React team deferring to these frameworks as a way to start an application tells you something about the fact that delivering on the vision outlined above no longer sits solely within the remit of React. The bits frameworks care about now become an integral part of delivering your UI to your users. What follows is that you might have to acknowledge that choosing React as your UI technology will now have potentially further reaching consequences and may come with added complexity. In other words, choosing React is no longer just choosing one of many flavors of V in MVC. 

This sounds like a lot of additional headache, doesn’t it? It doesn’t have to be! The whole point of the shift towards starting with a slightly more complex setup than just a SPA means that **you’re not locking yourself into a SPA** - and that’s a huge benefit as it saves you some serious grief in the future. Adding all the server-y bits to a bloated SPA is a complex endeavor. To avoid it, you may want to start with running RSC at build time (so react server components but – sort of – without a server) and then shift towards using whatever mode makes sense on route by route basis (and yes, there is a Dan Abramov tweet to back this up too). 

Does it mean that you should marry a metaframework? Maybe, and maybe not - either way, it’s now up to you to understand what such a framework does for you, and the answer is no longer simply based on whether you need SEO and hence need SSR. By the way, RSC is not the same as SSR. Server side rendering can be set up to play nicely with React Server Components though, and that’s partially also what metaframeworks do for you. 

One thing to consider is that server rendering runtimes are now a thing. As your UI app no longer lives solely in the browser, hosting becomes potentially more complex than just dropping a SPA bundle on a CDN. UI architecture considerations would now need to extend to deciding what your SRC server rendering environment requirements are. For example, Next.js now offers three different server rendering runtimes (node, node serverless, edge) - each with its own characteristics when it comes to security, latency, scalability and IO access and each with its own tradeoffs (e.g. code ran on the edge cannot exceed a certain size etc.). If you don’t want to be married to Vercel (the hosting company behind Next.js) - you need to roll your own. If you don’t mind tying yourself to a hosting provider, that has consequences too. 

Another thing to consider is that with SRC bundlers play an increasingly important role. Your bundler would now be tasked with generating serializable “module reference” objects, i.e. creating the server side placeholders for client rendered components, and then helping the client stitch the tree back together following the client rendering step. If you bootstrapped your project with a metaframework, this won’t be an issue. If you’ve got your own bundler setup, it might be something to look into. 

Yet another consideration is caching your rendered components (see static vs dynamic rendering in Next.js for an example of that). You might also be curious if your “backend for frontend” can rely on other technologies than javascript (not yet as far as I know, but that may soon change) and so on – there are potentially many more such technical challenges, which fall outside of the scope of this article. We’ll surely discover even more once the technology is mature enough to be production ready. 

What is obvious already, however, is that all of the above potentially impact the way you should source technical talent for react teams. Let’s look at why that is.



#### **What fullstack react means for sourcing React talent**
If the react community does embrace the metaframework first approach, one immediate consequence is that React skills will become less transferable. Familiarity with React via Next is not necessarily going to equate to familiarity with React via Remix - not to mention that we can expect to see meta-metaframeworks, i.e. more domain specific frameworks to be built on top of metaframeworks (e.g. Shopify hydrogen 2.0 is built on top of Remix). Each metaframework offers different abstractions and each is going to be incentivized to differentiate its offering. Competition is always great for end users, but bear in mind skill transferability may suffer. In your hiring you may therefore be well advised to pay more attention to the understanding of the underlying server related concepts, not framework trivia. 

Another consequence is that - metaframework or not - the mental model of react stretched across the network boundary becomes increasingly complex when it comes to debugging, optimization etc. Also, marrying the current client-heavy toolset with SRC may prove challenging. For starters, here is Jack Harrington building a toy Next.js 13 app using redux toolkit both on the client and the server and initializing the client store with values from the server store:

State Management for NextJS 13 Server and Client Components by Jack Herrington

This is to say that spreading React both on the client and the server may yield new challenges which you may want to test for or upskill towards. 

At this stage you may ask: is it worth all the hussle of revamping your HR practices just because one framework came up with a new feature? My answer in this particular case would be yes, if you believe this trend is wider than RSC - and I believe it is. 

Consider for example, that the same trend has been playing out in the C sharp world. .Net developers discovered the benefits of component based composability by going from MVC and razor pages to the Blazor framework, which came in two flavors. Blazor server, offering server rendered UI components, and Blazor Web Assembly, which works pretty much like every other SPA framework but relies on .net instead of javascript, crammed into the browser courtesy of webassembly. 

Now with .net eight on the horizon there is a new flavor of Blazor in town, called Blazor United, which promises to give developers the best of both worlds by allowing them to define which components should render on the server and which should be treated as client components. Sounds familiar? Here’s Jon Hilton explaining the details of how Blazor United came to be, and comparing it to Remix: [https://jonhilton.net/blazor-united/https://jonhilton.net/blazor-united/](https://jonhilton.net/blazor-united/)


This is not to say that server heavy UI frameworks are somehow a historical inevitability. The split between frontend and backend development is a valid one - at least for larger organizations. However, what seems to be more and more evident is that this split doesn’t align with the split between the server and the browser as neatly as we once thought. Instead the fault line seems to be between UI related concerns (spanning both server and frontend) and non UI related concerns. The talent sourcing consequences are pretty obvious if you look at it this way, and they go well beyond React. 

#### **Summary**
It’s still early days for RSC but it seems like it’s time to start looking at the details of what server-first React means for our organisations. 

#### **About the author**
[Jan Bełezina](https://www.linkedin.com/in/jan-belezina-7356055a/)
 is a software engineer and guest blogger for Bitnoise, based in Oxford. He specializes in React, Three.js, Next.js, and TypeScript. As a former product manager and business analyst, he has a wide overview of the development process and strategies.

Midjourney guide part 6: The puppet method

Kaja

The server-first future of React – guide for CTOs

Jan

GET IN TOUCH