More content yay

This commit is contained in:
Benjamin Bach 2024-07-09 19:30:21 +02:00
parent e33277a2a9
commit f7ec046bc5
No known key found for this signature in database
GPG key ID: 486F0D69C845416E
3 changed files with 23 additions and 6 deletions

View file

@ -132,6 +132,10 @@ There are several reasons why it makes sense for developers and designers to sha
<div class="collapsible-content"> <div class="collapsible-content">
The idea of "rapid development" has a long historical run-way, leading up to ideas like "ship early, ship often", agile programming methodologies etc. The idea of "rapid development" has a long historical run-way, leading up to ideas like "ship early, ship often", agile programming methodologies etc.
With rapid development, we mean that the developer should participate in the context/domain that the software seeks to solve problems and create value in. The developer needs direct feedback from seeing the software in use.
This in turn saves costly interactions and translations across actors. By fixing the problem here and now, we don't risk that the context is diluted, nor that elements are lost in transmission or translation between designers and managers. By letting the programmer be the designer, we in turn push responsibility and initiative to the user that gets to instruct the programmer directly. These methods are known also as co-realization and to expand "design space".
</div> </div>

View file

@ -13,17 +13,29 @@ We're focusing on choice and preferences. The objective is to make something tha
Ingredients: Ingredients:
* Open up your own design doc/enhancement proposal and start writing 1. Open up your own design doc/enhancement proposal and start writing
* The method 2. Establish your method
* Some components for evaluation 3. Choose components for evaluation
* tl;dr Conclusion 4. tl;dr Conclusion
One of the reasons why it's good to have this approach, is that most ORMs and API frameworks can be decoupled. But it's good to narrow down your search from the beginning. If you already have a strong preference for SQLAlchemy or Django, you should be comfortable with that choice. One of the reasons why it's good to have this approach, is that most ORMs and API frameworks can be decoupled. But it's good to narrow down your search from the beginning. If you already have a strong preference for SQLAlchemy or Django, you should be comfortable with that choice.
## The method ## The method
At the beginning, you should probably wonder about what criteria are important At the beginning, you should decide what criteria are important for your project:
* Do you want to build a prototype?
* Should others from your team participate in the evaluation?
* What should be the final outcome?
In my experience, it's worked great to do the following:
* An evaluation of any current setup and needs together with others from the team.
* Opening a draft design doc to capture all decisions and observations.
* Writing prototypes and doing small demos.
## Components for evaluation
## Th
## More resources ## More resources

View file

@ -3,6 +3,7 @@
<title>{{ if .IsHome }}{{ site.Title }}{{ else }}{{ printf "%s | %s" .Title site.Title }}{{ end }}</title> <title>{{ if .IsHome }}{{ site.Title }}{{ else }}{{ printf "%s | %s" .Title site.Title }}{{ end }}</title>
{{ with .Site.Params.description }}<meta name="description" content="{{ . }}">{{ end }} {{ with .Site.Params.description }}<meta name="description" content="{{ . }}">{{ end }}
{{ with .Site.Params.author }}<meta name="author" content="{{ . }}">{{ end }} {{ with .Site.Params.author }}<meta name="author" content="{{ . }}">{{ end }}
<meta name="fediverse:creator" content="@benjaoming@social.data.coop" />
{{ template "_internal/twitter_cards.html" . }} {{ template "_internal/twitter_cards.html" . }}
{{ template "_internal/opengraph.html" . }} {{ template "_internal/opengraph.html" . }}