Hi there I downloaded Anytime yesterday and found it quite daunting of what tool to use for which purpose. It seems a great tool though.
I want to create a plant database similar to PFAF which is based on pages that look similar to the pages created by pfaf which look like this: example I want it searchable.
Do I create a new object type “plants” or do I use “page” or “document” (what is the difference?).
Do I create a template for all / or a part of the plants? Is height, water,soil, ph, a relation or is it an object? I want at least ten of these parameters (soil, water sun…)
Is the Latin name, common name etc. a relation or a header? and is a description text an object? Are these blank spaces in the basic layout placeholders for text images etc?
Sorry for asking, but I could not find answers in the videos (they only talk about “humans” and “to-do lists”) Thanks for your input! Nicola
I suggest to create a new Type and call it “Plants”.
Then make a Template for it.
There you insert all the Relations you need. If necessary (it will!) create new Relations so that they fit your needs.
Then make (let’s say) three of these Objects “Plant”. See if everything looks fine.
After that, create a Collection.
Let it filter for “Object type Plants”.
Now add your most important Relations to the View in the Collection.
Later you can also add more Views to the Collection, for showing the Objects in some other way, or for specific filtering.
I like to use Tags for sorting my Objects.
So you could tag some plants as “healthy” or “poisonous” etc. and add a View for such categories.
But that’s only a suggestion, you’ll find out that different ways lead to Rome and that each way has it’s own benefits and disadvantages.
But that’s no problem, because most design errors are fast corrected after you know the basics.
But be warned: One thing can not fast be changed:
If you made a bad template and already have created an amount of Plant Objects, it unfortunately at the moment not possible to apply Template modifications on already existing Objects!
So put you most brainpower in the Template!
Don’t create too many of these Objects before your Collection works flawless.
You will see than if the Template is good and if it has all needed Relations when you’re working a bit with the Collection.
It will need its time and some changes before such a database really flawless works.
Often one finds need for adding some Relations more (but as said: changing the Template doesn’t change existing Objects!). Or there is need to change the principle of categorisation and so on.
It’s a process.
But after that, it’s a joy and you can fluid work with it.
It’s even somehow addicting then, so good does it work!
But at the same time it is also true that we could do good with a few further improvements and new features.
You’ll be happy like a child about each update!
Thank you! I worked sort of along these lines.
To make sure if I understand that right: if I make a template and later I want to add something like “cultivar” or “rootstock” both things would not show up in the plants I already did? That means I cannot add these values later? Also I cannot add anything you put in a new update later?
I miss very much figure -figure, say 9-11 which I could later sort into show me everything smaller than 10.
Anyhow the app is pretty good!
If your Plant-object template has 10 parameters as relations (soil, water, etc.) and then you decide you want to add an 11th then the added 11th relation will only show on new objects you create after updating the template and existing objects will need to be updated one by one.
When I first learned about this, my instinct was to add as many relations as possible. But I did it wrong: my instinct was to add all of the relations on the template page. Many of those relations were never actually used, or used only on a very small number of objects, making the top part of the page irrelevant for most objects.
The solution for that is to add these relations at the “backend” relations panel (the panel that opens when you click the triangle at the top-right of the object window). That way they’re there, readily available, but don’t create a visual clutter.
E.g., I’d put on the page all relations I know are always relevant to all plants (soil, water), so that I can quickly input them, but keep in the relations panel, hidden in the back, parameters such as “Poisonous”. When creating an object for a poisonous plant, then simply typing “/poisonous” will insert the relation on the object page so you can see it directly. Though, of course, you can also just tick that checkbox on the relations panel.
Another thing I learned the hard way: avoid using “text” relation for anything that you’d like to later group/sort by.
I would recommend using Sets in this case instead of Collections. If they ever create a plant from somewhere outside the collection, it won’t appear there.
Thanks, it probably takes a while to learn the ins and outs here! If I put relations in at the backend then I will not/forget to put it in while filling the forms and I can’t do a query re this relation am I right?
Why do you avoid text with relations? I didn’t use it often, but I did.
It was a bit of a learning curve for me, and the lesson I’ve learned won’t be relevant to everybody, but I’ll try to explain myself again.
Relations are a great way to add “metadata” to objects, making grouping disparate objects easy (e.g., all semi-shade plants that require infrequent watering and aren’t poisonous)
Since updated templates don’t reflect in existing objects, my templates grew to include lots and lots of Relations, anything that might be relevant in the future. This ended up occupying the top third of every new object, despite being grouped up in multiple parallel columns.
In reality, that’s not effective. I’d like to be able to mark a plant as Poisonous or Edible, but 90% of my house plants are neither. So the lesson I’ve learned is broadly this: if I don’t see myself actively filling the Relation for 80%-90% of future objects, I don’t display it on the template. For the few relevant cases, I trust myself to remember to add the relation to the page (typing “/edible”). What I don’t see and don’t care about simply stays empty and out of sight.
As for Text-type Relations: the main shortcoming is that they don’t allow to grouping Objects together, which is the main utility of Relations. Another major shortcoming (which I hope will be fixed) is that they can’t contain any text formatting (e.g., bold, italics, etc.). In your use-case scenario, a Text-type Relation would be relevant for something like “Latin name”.
You can simply delete the Relations from the Template’s Canvas (the editor).
They will still be there (for sorting in Sets or collections) - look in the triangle at the upper right corner. They are there!
But they aren’t longer visible on the Editor’s Canvas.
A second hint:
You can also use a Toggle by typing “/toggle” and move unnecessary Relations or other things in it. So you can hide or show things by a single mouseclick.
That becomes handy if you want to store a lot of things in the Object, without having them in the printout.
But the better way in your case is to remove the Relations from the Canvas in the Template.
You can restore a from the Canvas removed Relation by typing “/ne” (for Add new Relation" followed by the Relations name.