Some of the Tryton’s Spanish Integrators had a meeting today and we agreed that we have to join forces to improve the visibilty of tryton for newcommers. Here are some points that we discussed:
Improve Tryton webpage giving a more detailed explanation of new features.
We also discuss the possiblity of giving some funds to the Tryton foundation, so some of this of this tasks can be purchased to external suppliers.
I will like to know the opinion of community members of other countries. Specially answering the following questions:
Do you think there is any other topic that can improve Tryton visiblity?
Are you interested in contribution (with work or money) to some of the topics?
Did you have any issue that prevents you to contribute to some of this topic? For example, if you have some success story of some of your customers but you did not contributed it back to Tryton it will be great to hear why you didn’t to see if we can improve something.
I’m waiting for your replies!
P.D: If you are from Spanish and you want to join the future integrators meetings feel free to send me a PM and I will be very happy to keep you informed about future meetings.
P.D: If you are from another country and you are interested on having some live meetings to share experiences of Tryton, please let me know to see if we can organize one.
I think a short introduction video should be good. Like a demo with key features, one for the erp and maybe another with more technical view about framework capabilities.
Really is necessary to have more detailed and simple information to reduce the Tryton learning curve.
It is very good for the promotion and motivation of the implementers to add more success stories and references from companies and / or people that implement Tryton.
Creating documentation for the end user is very important because it allows more people to use Tryton, it is easier to handle something that you have the information on how to do it, than wasting time on something that you should gradually know.
It would be interesting to create official step-by-step documents reviewed and approved by the foundation and then promoted and used by the implementers to create a standardized use.
The money is necessary to be able to invest in advertising and marketing strategies by specialized companies to increase the presence and increase the reach of Tryton.
first Content Amplification and later implement a referral system.
Yes.
It would be interesting to publish the success stories of implementation that we have achieved since 2017 to date but we sent to the email foundation@tryton.org and we had no response.
It would be good to regularly organize live meetings to increase interaction between community members.
It is a very good idea even if it seems silly but even create videos of each process, how to create a product, or create a customer or create an invoice, video of each process explaining it. Today people are more attracted to video tutorials.
For me before reaching the advertising stage we shold focus on improving the website and create more content on it, so we provide the best experience for users comming to our site.
Sorry but I’m lost here, could you elaborate what are you talking about?
Live meetings is always harder than asyncronous posts. So it will be good if you share your toughs on the discuss forum. Once we agreed on some topics to talk we can organize live meetings that anyone can join.
There was the idea of creating scripted videos some time ago but we did not agree to which tool to use and nobody produced a sample video to start working on. Any help on this will be much apreciated.
Using scripted videos allow us to generate content in multiple tryton series without having to re-record them on each relase. This will ease a lot the mantenance of videos and will allow us to keep them always up to date.
The group is composed of ~40 book editors who decide to cooperate to build a edition-specific solution.
The are creating an association to manage all aspects.
The offering will be composed of a software product and services.
Product part will be built on Tryton, with standard Tryton contributions and industry specific modules, pre-setup scripts, documentation, and product roadmap.
Services part will include implementation service, custom developments, technical hotline, training and Saas for new adopters.
As a typical example of consequences, I’m building a turn key “Saas as a service” so this kind of community can include a Saas proposal since the beginning.
This kind of industry-driven community gets great advantages in choosing tryton and to tell the truth, they have little choice because most alternatives are products to be used “as is”.
They expect Tryton to provide technical/business “enablers” to build there own strategy/offering/knowledge and as such, a better presentation of Tryton will help. So they will be interested in all your initiatives.
In this context Tryton resources will not be used by end users in this context but though intermediate communities. These communities must create dedicated documentation focused on the pre-setup they promote. And they expect the pre-setup to simplify a lot adoption by new users.
Exploring the path to such ecosystems is my strategy. There are several open opportunities for groups of associations, social business, crafting and cooperatives.
If done properly, this is a massive task, not just because creating good documentation in the first place is time consuming and requires in depth knowledge of Tryton, but much more importantly it needs to be kept up to date and maintained. I also think that this maintenance is not something that the core developers should be burdened with or even have to think about.
I know this is something that has been discussed before, on more than one occasion and from what I can see there have been quite a few different attempts at creating user / administrator documentation with varying degrees of success, but many are now out of date or seem to be unmaintained, here are a few:
I also think that, although the official Tryton documentation is an excellent up to date reference point (especially for developers), some potential users go looking for more detailed user / administrator documentation and come across some of this documentation listed above. This then may be confusing some people or giving them a impression of Tryton as it was 5+ years ago. So having up to date, well maintained, end user documentation would then fill that gap.
Although, and I am fully aware/concerned this may end up just adding to the list I gave above (so a bit like this: xkcd: Standards), I am trying to take the best ideas/parts of that documentation and create a comprehensive Administration and Configuration Guide and User Guide for Tryton, which I am planning on working on when I get time. Any comments, help or contributions would be most welcome.
Tryton is not only about developers, it’s about a community. I think any one can and should contribute to the project in some way in order to improve it.
We all know that it is not an easy task to reach the goal to have a good documentation but I think it is a must.
Maybe we should take a little step away and learn from the older initiatives to build something better, maintainable and reliable.
I guess we will find the trick making little but strong steps to our common goal. Maybe beginning with something as humble as howto/recipes would be a better path to reach it, who knows, but for sure, I absolutely think that we have to do something as soon as we can.
For me the reason because those initiatives all failed is because all of them started by some individuals and they where developed out of the tryton repositories so never became an “oficial documentation”.
If you plan to work on this in the long way I think we should first discuss how to develop a documentation, which topics we should include on it and then do a collaborative effor. This is the only way to include the documentation as part of the oficial documentation and do not have a new failed attempt. It will be good to start a new thread for this discussion.
Another point that we failed to get documentation is that we have the fear to have an uncomplete or outdated documentation. For my point of view, both documentations are better than no documentation. I think we should low the starting point of the documentation and write them step by step. Once we have some patterns and some starting point we can use a crowdfunding campaing to make someone work on it.
I will prefer to do not have any hurry on this topic but do little steps to complete a long way. But what is clear is that someone have to take the initiative.
IIUC your comunities will be a bridge between Tryton comunity and the industry spefic end users.
So I’m wondering if it will be good to involve them on the Tryton documenation part, so they can benefit from our content (by including them on their specific documentation) and they contribute back to the project. A win-win for all!
They certainly will. Nevertheless, I see two difficulties
The language: We need a Tryton documentation in English but local communities will only work in local language.
The fact that Tryton is “generic” and consequently far more complex than what a dedicated solution must be. Indeed Tryton documentation cannot make assumption of any particular use of features, and the more open you are, the more difficult it is to provide simple information. On the opposite, an industry solution must be simple, else it won’t be adopted. To make it simple, we limit the way features can be used. For example, a specific setup will select supported modules and initial organisation. Stock locations and properties will be pre-defined to match a typical activity. Accounting will be fully set. Documents default formats will be adapted. Therefore the documentation to end-user with go straight to the point and will only describe a subset of Tryton capabilities.
I think we can not think about having something in local langauge before having an English documentation. So for me the first starting point is english and once we have something that is usable we can start translating it. It’s moreless what we do with the tryton website,
As far as they describe some of the features it’s enought for me. A subset is always bigger than an empty set
I didn’t talk about Tryton documentation there. A localized guide line is a requirement for these groups, and they will probably not translate much from a generic Tryton documentation.
I don’t know what is possible to avoid multiple effort.
Therefore the documentation to end-user with go straight to the point and will only describe a subset of Tryton capabilities.
A custom procedure may be misleading because it depends on the organization and the implementation and favors a specific way of doing things, unfortunatly.
Let’s see what can be in synergy while things progress.
