Learning curves and what is what [was: Extra fields in the (upcoming) admin]
Marc Worrell
Fixing and clearing up nomenclatura is important indeed!
Let's see...
On 3 apr 2012, at 22:47, ll...@writersglen.com wrote:
> -- Some of them have an explicit technical meaning in Zotonic that may or may not be well defined in documentation (thanks Andreas and Michael for your help with resources and edges).
We need a 101 on this kind of stuff.
The conclusion of all our discussions will be good food for filling that part of the documentation.
> -- Some of the terms have other meaning in other contexts (I don't know if it's still used in Zotonic docs, but the term "page" for what I'm presuming is now called a resource, really threw me off when I first came into Zotonic, having confused with html page.)
Page =:= Resource.
The resources were always called resources.
But then came some user testing of the admin and a totally confused tester.
Tim then concluded that 'page' was the best description of a single resource.
Also because of my mantra that every resource has its own URL (which is also a HTML page).
> For me, having a firm conceptual model with terms that have clear and explicit meaning makes all the difference in how quickly I can learn about a complex system like Zotonic.
Always important to have the bird-eye view.
I need it when learning a new system as well.
And Zotonic grew quite large in the last couple of years...
> At risk of confusing the waters and, perhaps, sounding tediously pedantic, let me share some things I've been thinking about web development. I throw this out not to impede current work-in-progress, but as food for thought and discussion related to future work.
>
> 1. The browser sees streams of simple text stings and binaries.
>
> -- Strings and binaries, in other words, are the products of all the logic we cobble together to create our web development tools.
True, inside the server any page/picture/whatnot being served is just an iolist().
It is up to the user-agent (and the user) to make something from it.
> 2. These streams are formatted to represent human-readable text, links to images, html markup, css markup, and javascript
>
> -- They embed and intertwine information for both the machine and the human consumer.
Yes.
Which makes reading templates sometimes hard to understand.
> 3. Since the strings are too extensive for our limited minds to process as a whole, we "chunk" them into conceptual components that we call resources, templates, css styles, etc.
>
> -- Other frameworks may well use different terms for the same concepts, which can contribute to possible confusion.
>
> -- The way we conceptually "chunk" the browser streams may well require us to cross several semantic and syntactical boundaries.
>
> -- We may need different tools and interfaces to create and edit the various chunks; e.g. a text editor for human content, a template editor and language for html; an editor for css, a menu tool for creating links between html pages, etc.
>
> -- Depending upon documentation and interface design, this conceptual chunking may well impede learning, productivity, and extensibility of the system.
>
> 4. Suppose we were to use a different conceptual scheme for "chunking" the stings of characters we want to send to the browser? Could we find a way that's conceptually consistent, easier to learn, more productive, and more easily extensible?
Good question! And an intriguing though...
> -- A key idea here is to determine what the computer can do best vs. how the content creator thinks about, creates, and edits content and presentation.
>
> -- In a perfect world, the computer would do all the tedious, repetitive stuff. The human content creator would focus on the intended audience and the message. This is a significant challenge for the system/tool developer.
>
> -- Question: To what extent should the technical specialist, e.g. the web developer, stand between the content creator and final presentation?
>
> -- I think of the web a a communication medium with a bias toward content creation and consumption so, from my point of view, the less impedance between me as content creator and my audience the better.
>
> 5. I'd suggest that we're working at three different levels when we develop tools such as Zotonic for web application development.
>
> -- Conceptual: Here we want clarity of concept and terminology for human consumption.
>
> -- Representational: Here we want consistent data structures appropriate for the computer language and databases we're using to implement our conceptual ideas
Also called: model
> -- Translational: Here we're talking the language of the browser: html, css, javascript.
Often called: view
> The process of web application tool development moves from conceptual through representational to translational; e.g.:
>
> concept -> representation -> translation
>
> Let me now attempt to define a specific set of terms for use at the conceptual level. If we were ever able to achieve clarity and consensus at this level then, I'd argue, technical development of web tools in whatever language would be much easier.
>
> Keep in mind, I'm not suggesting that this set of terms is the best or most descriptive, or that we should adopt it. But I throw it out as an example of what I'm talking about. The key point is that each term in the scheme means no more nor less than its explicit definition:
>
> content - text and images for human consumption
>
> content element - a chunk of content as conventionally defined and understood by content creators and consumers.
>
> -- Each content element has a type; e.g. paragraph, image, list, link and, optionally, a name or id.
>
> -- content elements may also be paired with a style specification for presentation purposes; e.g. emphasis or consistency of graphic design.
>
> blurb - a list of content elements. A blurb has a name, a default style, and an optional id.
>
> -- a form or stand-alone unit of functionality, applet for lack of a better word, would also be considered a blurb.
>
> box - a two-dimensional display or presentation of content. If the box displays a blurb, then we'd call it a container. If it contains a list of boxes, then we'd call it a wrapper.
>
> -- boxes can be styled for size, position, and borders.
>
> -- container boxes may have default styling for related content.
>
> panel - synonym for wrapper.
>
> Given this, we can say that the body of an html page is a panel that defines the page grid. Each box in the panel is assigned a blurb and a style specification. Each blurb may also be assigned a style specification
>
> Given this vocabulary we have, I think, all the concepts and terms we need to talk about web application development system design and the tools we need to meet the needs of content creators without reference to technology.
In Zotonic we use (at the technical level):
- property: a title, body, publication date etc
- medium: a file, image, youtube video
- resource: a collection of properties and optionally a single medium
- edge: a meaningful connection between two resources, where the predicate defines the meaning.
And for the representation:
- a page template (which might be a variation of another template)
- template snippets (included by the page or other templates)
- library files: images, css, javascript
Where we have additional constructs to help define the logic in the templates or map URLs to templates/controllers
(a controller is a webmachine resource).
> When we start thinking about technology, however, we enter the second level of discourse: representation.
>
> Given the programming language we chose to employ for implementation of our design, how do we best represent the concepts defined above as data structures supported by that language?
>
> Currently, in Zotonic, we have four very different data structures: Postgresql tables, Erlang structures, html files, and css files. Javascript should also be considered here.
>
> This, to my mind, limits us in several ways:
>
> -- More to learn and master for fluency
> -- Risks confusing our thinking and discussion about the system
> -- Increases system complexity
> -- Reduces opportunity of modularization
> -- Makes maintenance and extensibility more difficult
> -- Makes adoption of new technologies more difficult
>
> So, back to the question. Can we do better?
>
> Fortunately, I'd suggest, all of the concepts noted above can readily be represented as Erlang lists and tuples.
Do you suggest to define the HTML/CSS/JS as Erlang tuples?
Front-enders like to be able to control all HTML (etc) with their own tools.
It is their lingua franca.
One of my ideas is to have a separation between this front-end world and the back end world.
So that the front-end people can do what they do best.
And the back-end people can do what they do best.
Though, I must admit, there is still too much gray area.
I think that much of that gray area might be cleared up with:
- better insight what happens when a page is served/generated
- debugging tools for the front-ender
- maybe tools to easily try out things (what if scenarios)
I think I would love these tools.
What would be needed?
> Once represented as Erlang lists and tuples, it's a fairly straight forward task to translate these structures into strings suitable for submission to the browser.
>
> The task of translation, I'd argue, is best performed by the computer, either at the create-time or execution stage-- making it easier and less error-prone for the computer.
>
> I can see only two possible drawbacks in this approach: It arguably makes more work for the tool developers; may result in performance penalties in production.
Don't worry about performance, that is our job :)
> I'm running out of steam here, but actually have some code and am happy to explore this stuff further and share may code with any all interested.
I am happy to see more of what direction you are talking about and how that helps you.
Best,
Marc
ll...@writersglen.com
This and your last few posts on these issues begin to plow really fertile ground.
Unfortunately, I'm headed out of the country in a couple of days so have been pushing hard to get work out and prepare for the trip. So, I may have to pick up on the topic when I return in late April.
But, here are a few of the insights I've been working with.
Keep in mind that I'm a writer/publisher. So everything I suggest is strongly biased in that direction:
1) I want to keep everything I write in plain text and simple files for several reasons.
2) But I want tools to mark up that text for presentation and publication; in my case, html and latex. I'd like these tools to be as intuitive, easy to work with, flexible, and responsive as clay. Productivity is VERY important to me.
3) Insight: Most such mark up involves wrapping text in tag strings.
4) The Erlang data structures and funs provide an attractive way to store and wrap units of text given a data structure something like:
{wrapper function for html, wrapper function for latex, unit of text}
5) A body of text can be represented as a named list of such structures.
6) This approach can accommodate as well images, links, and lists.
7) These structures can be easily translated into html, latex and/or PDF output.
8) These structures should also be easy to edit on-line with Ajax and JavaScript. So, in theory, very user friendly tools could be developed to edit them.
9) By the same token, my presumption is that graphic designers would much appreciate similar tools that give them immediate graphic feedback-- like clay. The data structures that I'm suggesting, combined with clever Ajax and JavaScript should make this possible.
10) Front-end tools should also be modular -- mix and math; different horses for different courses.
11) The kind of documents I work with, for the most part, do not require the full power of a relational database. Indeed, my experience to date suggests that trying to store them in a relational database introduces various hassles that I'd rather not deal with.
12) But I can easily see many use cases where relational db functionality is invaluable.
13) So, for these reasons, I have a strong feeling that back-end persistent storage should be modular and database agnostic. Chicago Boss has moved in this direction. I haven't evaluated their solution, but it may be worth looking at.
14) To carry these ideas to ultimate conclusion, however, we do need a select/search/sort language that relates conditions in the request to data queries. The Django language may be ok. But wouldn't it be great for sake of productivity if we could also have a visual language. The Erlang MFA syntax offers interesting possibilities.
I'm reasonably far along with code based on these ideas. I'll try to tie it together and share when I return.
Should have crashed two hours ago, so, bye.
All the best,
Lloyd
ll...@writersglen.com
http://infrequently.org/2012/04/bedrock/
Best,
LRP
-----Original Message-----
From: "Marc Worrell" <mwor...@me.com>
Sent: Wednesday, April 4, 2012 5:03am
To: zotonic-d...@googlegroups.com
Subject: [Zotonic-Dev] Learning curves and what is what [was: Extra fields in the (upcoming) admin]
Hi Lloyd,
Let's see...
Page =:= Resource.
Also called: model
Often called: view
And for the representation:
Best,
Marc
-----Original Message-----
From: "Marc Worrell" <mwor...@me.com>
Sent: Wednesday, April 4, 2012 5:03am
To: zotonic-d...@googlegroups.com
Subject: [Zotonic-Dev] Learning curves and what is what [was: Extra fields in the (upcoming) admin]