to change to the program. But let's start with our invited speaker, Victor Olaya. Thank you very much for coming, and Victor is a well-known contributor and a well-known person in our community, and we are really glad that you have been able to come and to join us, so please.

Thank you. Yeah, thanks to the organization as well for inviting me, really happy to be here. I'm going to be making a small presentation, a kind of philosophical presentation,

about the importance of knowledge and of good education and knowing what we are doing with our GIS. This is what I call here, being a better GIS professional and how we can help other people become better GIS professionals. So for those of you that don't know me, I'm basically a GIS developer, and if I have to select

from my career like the two highlights, let's say, of my career, the two most important things I've done, one of them would be the processing toolbox, in case you're familiar with QGs, this is the entry point for all the analysis in QGs, I created that five or six years ago, I don't remember right now. That I would say is probably the most important hit in my career, but I've done other things

apart from development in the world of GIS, and there's another thing I'm really proud of is this book, which is, as far as I know, the only free book about GIS theory, it's a book that you can copy, sell, modify, like a free book, like an open source book.

This picture was posted to Twitter by one of my readers, it's the book on a weight scale saying that this book is 1.5 kilos of knowledge, and you know, it's a pretty big book, it's almost 1,000 pages, I did a lot of work on that, and the book is pretty

popular, and there's now a shorter version in both Spanish and English, so with these two things you can say that I've probably been doing two things in the world of GIS, one is providing useful tools for GIS professionals, having that platform for analysis, and the other thing that I've been doing is teaching, I've done some training courses, but

with this book people read the book and people learn GIS, right, it's something that I actually like a lot, to teach other people, but I believe that I've not only been teaching people with my book, or with the training things that I do, but also with my work as a developer, right, I think we are in the open source world, we are in the community, and everything we do in the community affects other people, and that means that when

we do something, we are actually teaching other people, we help other people become better professionals, we might do that correctly, or we might do that wrongly, right? So this is what I'm going to be talking about, as I said, the importance of knowledge, of knowing and understanding what you're doing in GIS, but also how we can teach

other people, we can help other people become better GIS professionals, not just by doing things that, you know, we might classify as training or learning, like writing a book or doing a training course, but also in everything we do in the community, and starting from my main job, which is actually coding and programming, right?

So let me start with a quote, this comes from Phosphogee Barcelona, this was from one of the keynote presentations, and at that time, we had already opened street map, but it was not such a big thing, and a conference like that, like Phosphogee was really targeted at software, and then came this keynote

speaker and said, hey, yeah, it's fine, you are focusing on the software, but don't focus exclusively on the software, because data is also important, and you have to focus on data, we have great software, but we don't have great data, that is not useful, right? Your software is awesome, but it's useless without data, that's what he was saying, and I completely agree with that, I think it's really true, right?

But I feel that it's half true, that it's not a complete truth, because it just moves the problem from the software to the data, right? We are not going to focus so much on the software, like having great software, and we think that it's going to solve all our problems, we move to data, but kind of we're in the same situation, right, because this is not

the complete thing, right? I'm going to use a metaphor to change that, I've used this, this slide in another talk, probably you've seen that, you've seen me do it in other talks, but I like this metaphor, David and Goliath, everyone knows this story, right? David is small, but he's smart, and he defeats Goliath, because he uses his link, so that's the moral of the story.

And, you know, to see that, let's analyze this, what happens in here, what are the elements in this fight that explain what happens, right? The first one of them, of course, you would say, is this link, right? It's the first thing you think about, okay, yeah, David has this link, that's the reason why he wins, he's smart, and he uses that.

This is what we can say is the software, right? Software and hardware, maybe, but it's like the tool that he's using, right? It's a tool that he uses as a weapon, and of course, his link might be awesome, but it's useless if you don't put anything into it. It's useless if you don't put stone in it, right? We have this link, we have the stone, and the stone, obviously, is like the data, that's what we use to feed your tool that you have there.

So if we stop in here, if we just focus on, yeah, having a great link and having a great stone, yeah, we're still in the same problem, because there's a third ingredient, there's a third thing that is more important than both of the other ones, and we usually forget, you know, the third element, if you can figure out, it's aim, right?

If you don't have aim, if you don't know how to use that, you can have the best sling, you can have the best stone, there's no way you can win that, right? This is the most important thing, to train, to learn how to use a sling, and then, okay, it's better if you have a good sling, and if you have a good stone, but the most important thing is the know-how, right? Having good aim and knowing how to use it, right?

So this is basically what we try to have as well in any discipline, but especially in the case of GIS, right? Let's not focus so much on the data or the software, which are very important, like in a conference like this one, we're discussing about software, about data, but also focus on, you know, being, as I said,

good GIS professional people that actually understand what they are doing and have the know-how that is needed to write. We can rephrase that quote from the first video. Like that, your software and your data are awesome, yeah, but they're useless without knowledge, right? We have to know what we're doing, and most of the time, we forget about that, right?

We just not think about that so much. By the way, what I'm going to try to do now is to, yeah, let's see how we can go in that direction, how we can guide people to become better GIS professional and get more knowledge instead of just focusing on having a better software or a better data, right?

Here's one tip that I would give to you. If you are a software developer, what to do to get that, to make better GIS professional? Let's make software less easy to use, right? And, you know, I'm going to propose a couple of things here in like a provocative way, right? But I'm not saying that we have to make software, you know,

we have to focus on making our software less easy to use, but also we shouldn't focus on making it easy to use, like, per se, like, you know, this is a goal. Let's make our software easy to use. Software has to be efficient, software has to be effective, intuitive, robust, many things,

but not necessarily easy to use, right? Or, you know, this is something good, but it's not something that we should focus on that, like, you know, so important, you know, why? But basically, because easiness is not a substitute for knowledge, right? And what we try when we do something easy to use is just making it more accessible for people

that don't have the knowledge to use the non-easy to use version, right? And this is not a good idea, we have to make it easy to use for people that already know what is needed. I like to think about a programming software, the kind of software that we, the programmers, used to write our software, right? There's a big difference between using a text editor

and using a programming ID, right? You have auto-completion, you have syntax checking, you have a lot of things that make your life easier, right? So it's easier to program with that. But in the end, you must know programming. There's no way that using the most advanced environment for programming, you're going to be able to create a software if you don't know how to create a loop,

if you don't know about data structures, all the kind of things that programmers, we know, right? So you need to know the language, you need to know the programming stuff, and then you have the tool that makes life easier for you. And this is what we should try to get also when we are developing software for GIS, right? Making it easier for people,

or making it more efficient for people that actually know what they're doing, but not try to mask the complexity and replace the need to know what you're doing with just, you know, something that's easy to use, and that you believe that you understand what's going on in there. Oh, this should, hmm.

This is a quote from Rick Cook, that's a 20-year-old Bob but it's still, it makes sense now. I'm going to read because you don't see the last part. Programming is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots.

And what you can see is that so far the universe is winning, right? So this is the quote. And I believe this is still true today. This is, as I said, this comes from a book by a writer called Rick Cook, written more than 20 years ago. And what we're trying to do here, like this is true, and how are we fighting this? Well, what we're trying to do is to build better idiot-proof programs

because all this idea of easy to use, in the end, as we usually use it, as we usually approach that, easy to use is just an euphemism for idiot-proof, right? And this is not the good way, I think, of doing things. We are trying to create better idiot-proof software, but instead what we should try to do, as all these people that are idiots,

and probably this is not very politically correct, but I keep the phrasing of the original phrase, right? But let's try to make the people so they're not idiots. They become smart and wise users. That's what we have to do. That's a better way of trying to win the universe, right?

Because the universe is going to always win as if we are using this in this approach, trying to write better idiot-proof programs. What we should try to do is to change people so they are not idiots anymore, so they just become competent users, like wise and smart users that understand what we are doing in our server.

And then we don't have the need to make our software idiot-proof or easy to use for allowing that people to use our server, right? Another idea that might be a little bit dangerous is this idea of user-friendly. We try to be user-friendly, and this is good. It's good to have the user feel good

when you use our software, but sometimes it just, it seems that we try, like developers, we try to create something, or the developers or the people that design software, which are not the same people always, they try to just make the user happy. And yeah, that's good to have the user happy, but that doesn't guarantee that the user

is correctly using the software or correctly doing GIS, right? And I think we don't have to think about just the user, let's say just the user, the immediate user of the software, like the person that is using the mouse and the keyboard. We can consider like the user of a software is all the people connected to that, right?

If there's someone creating a map, that's the user of the GIS, but then everyone that uses that map is an indirect user, right? And we should try to keep that people happy, not just the person that plays with the software, but then the people that use all the results, right? And what is the best way of doing that? It's not by making it user-friendly interface or something easy to use.

It's by making an interface to guarantee that whatever's done with the GIS is good, right? It's a good map. So then everyone connected to that user, connected to that map that he's preparing, everyone will be happy because he will have a good map to use, right? This is, we have to expand this idea of the user and then make user-friendly, but for everyone connected to the software, right?

Not just try to make the user happier, right? The goal is not to create a software that satisfy the user, and especially not by making the user think that he's good enough, like that, you know, develop this false belief, like, oh, I can do that, right? It's very easy. Now I'm a GIS guru and I just click, click, click, click three times

and I get something. No, there's no like that. This is false belief in that. That is not the way to have a good GIS professional, I was saying before, so I'll put it in another way. So the goal is to create a software that generates satisfying results, not for the user, but for everyone that uses that, right? And in a more direct way,

I don't care about happy users, right? I care about sound results, right? The software has to guarantee that the results that are created with it are correct, right? Even if the user is not happy. If it's better, if the user is happy, but that's not the main goal. The main goal is to have a software that produces interesting and soundy software.

Let me show you an example of a software that is a fantastic software, but it's a good example of that I've been saying. This is a proprietary tool, it's an ESRI statistical analyst. I'm not doing that in Porpoise. I mean, I'm going to speak bad about this, but I'm not doing it just because it's a non-open source.

This is a good example. So as you can see, this is pretty complex and this is really powerful. This is a fantastic tool. It has a lot of tools for doing interpolation, et cetera. But the bad thing is that if you want to use that, you should understand everything that is in there, right? Because tier statistics, for those of you that are familiar with that, probably you know that tier statistics are not easy.

It's complex, right? And you need to understand everything in there. The problem in here is that this is a wizard, right? And the wizard is something that, you know, if you think about yourself, probably everyone in here knows more or less a little bit about computers. So when you install a software, wizards are for people that actually don't know much about installing software, right? Other people, you just install it in a different way

because it's more flexible because you can, you know, select more parameters. Even more efficient, you can automate things. You know, it's better. Wizard is for people that don't know how to do that really, right? So if you're installing a software, might be fine. But if you're doing some, you know, advanced statistical stuff, you should know what you're doing, right? You shouldn't need a wizard, right? And the problem here is that you have this kind of wizard

with a next button. So basically you put your data, no matter how bad your data is, no matter how much understanding of your statistics you have, you click on next and in the end you get a result, which is likely to be 99.9% of the time wrong because you don't understand what is going on. But at the end, you get your layer. And it's like, oh, I got some points from rainfall stations

and now I have a rainfall raster layer. We're checking these for those things, right? And yeah, you get a result, but that doesn't guarantee the result is right because there are so many parameters to adjust and you should understand them, right? These is a good tool in the good hand, but in the bad hand, if you're someone who is not really an expert

or know something about your statistics, they can lead you to believe that you're good at that and believe that your results are good when that's not true, right? So this is the kind of thing that I would say is not the kind of software that we should create. This is not a software that makes the user become a better GS professional, right? Just the other way.

Make the user believe he's a good professional. Well, he's not, right? We can also analyze that. We, still from the point of view of the programmers and software designers, from the point of view of UI UX. I'm sure you've heard about that. UI, user interface, user experience, right? And I'm gonna make you, put you a small example.

Let's think that we have a light bulb, right? And we needed an interface for that, right? We needed an interface for turning on and turning off the light bulb, right? And this is a new interface, right? Let's think about that from the point of view of UI UX. Is it a good user interface? Yeah, I think it's a good one, right? It serves its purpose.

You can turn on and turn off the light, that's fine. From the point of view of the user experience, is it a good user experience? Yeah, it's pretty intuitive, it's easier. It cannot be easier than that. It's very comfortable for turning on, turning off a light. So that's good in terms of UI and UX. Now let's change the scenario.

Let's think that at the other end of the button, there's not a light bulb. There's an atomic bomb, right? And let's do the same analysis. Is this a good UX? Yeah, that's a good user experience. You can drop a bomb just by doing a single click. Okay, that's pretty easy, right? Is this a good user interface? Definitely not, right?

When you're planning a user interface for a control to drop an atomic bomb, it should be a little bit more difficult to use than that, or safer to use, right? You need something more or less like that, right? And let's do the same analysis. Is this a good user interface? Yeah, it's a good interface for an atomic bomb. Is this a good user experience?

No, it's terrible. You have to switch, you have to switch one key, the leading, it's not a good user experience. It's not comfortable, it's difficult to use that, but it's a good user interface, right? So we have to make this difference, not just focus on the user interface and having the user happy, right? And something that is easy and comfortable to use, right?

You might think that I'm exaggerating a bit, like this is about throwing an atomic bomb, right? So yeah, we are doing GIS. But then if you think about the things we do with GIS, first we do military, people do military things. You cannot drop a bomb with a GIS, but you can calculate where to drop the bomb, right? So we're doing that kind of things.

But even if you're not doing that, we do a lot of things that are potentially dangerous, right? We use interpolation to go from rainfall data to a raster layer, then then we might use to do some hydrological analysis to compute rain-off, and the data from the rain-off, we use that to calculate the dimensions of a dam,

a dam that if it breaks, it might kill people, right? So what we're doing is not something, it's not always dangerous, but it's important. And we are doing important analysis, serious analysis that might have consequences on people. And I think it's better if we have some sort of safety around our software. And the safety is not just by making it difficult,

like in this case, but by making our software available to people that actually understand what they're doing, not to anyone that can click a next button, right? So this is more or less what we have to do, right? Here's another quote. Sorry, no, this is a quote by myself. So I just rephrased the year quote,

so we can rephrase the quote that I used before. Like your software and your data are awesome, but actually they might be dangerous with our knowledge, right? We need to know about what we're doing, but otherwise we might do things that they might be, they might be dangerous, right? Another quote by Rick Cook, the same as before,

I would say with this last, you know, of those three most dangerous things, the last one is probably the most dangerous. It's a user with an idea, right? We have users and developers, we like to keep our users happy and we listen to your users. And that's really good, that's really good. We don't have to create something just made by developers for developers.

No, no, no, we need to target the people that are using our software, right? But sometimes users, they have bad ideas and sometimes they propose things that are not right. They like something to be easier or more, you know, whatever, and it's not like that. It's like, you know, if you learn your stuff correctly, if you have the knowledge that you might have,

then you don't need that to be done, right? So it's good to listen to your users, but it's not so good to just, you know, believe them in everything they do or think that they're right and they know what they need, right? So that's important. And if these are the three most dangerous things,

I would say there's one even more dangerous than that, which is not a user with an idea, and it's a user with idea and money, right? Which is basically what we call a client. And I'm saying this because it's, you know, it's easy to say that, maybe it's not so easy to actually do that, but I'm sure that you all have seen users or clients

that ask you to do something that doesn't make sense, right? Something like, oh, I have this organization and I have 500 computers. Why don't you make this a little bit easier with a big button here so everyone can use this software for terrain analysis? Like, no, it's easy enough already. Let's just teach your people how to do that.

Don't make me create something so it's easier and more idiot proof for all you, everyone there, right? It's easier to say that than to actually do it, but you know, the spot of the client is always right, it's not, the client is not always right. The client has the money, right? That's it. And the clients with the money might ask us to do some work that maybe doesn't make sense,

or maybe it's not the best thing or the best way to actually go in that direction that I was mentioning of creating a better GIS professional, right? Okay, so this is more or less about the software, like, you know, as a software developer, as you can see, we can do a lot of things to guide people in the right direction, to actually teach people and help them become better GIS professional,

or at least not to, you know, to avoid putting them in the wrong direction so they believe they are good users, well, they are not, right? What about other things in the software, like the documentation, right? How can we do that? Okay, say, let's write less documentation, right? And again, this is in a provocative way,

you probably know that people complain that open source software is poorly documented, blah, blah, blah, and that's true, that's true. We need to put more effort on the documentation, but we need to put effort on the kind of things that are useful, not put effort on other things, and in many cases, we're documenting things that we shouldn't be documenting, right? Or things that by documenting them that way,

we are, again, putting the users and people reading that documentation, putting them out of the correct way of learning GIS, right? So this is like the golden rule, I would say, of documentation, is it looks pretty obvious, right? But documentation explains the software, and this looks pretty obvious, but it's not.

Sometimes we try to document things that are not in the software. If you think about not a GIS software, let's think about a software to write, yeah, word processor, LibreOffice, OpenOffice, Microsoft Word, whatever. If you go to the hell files, think about the things we do with a software like that.

We write letters, we write documents, we write poems, we write short stories or novels, whatever. If you go to the documentation, it's not going to tell you anything about how to write poetry or about storytelling. You're supposed to know that. If you want to write a novel, you should know about storytelling, about how to create characters, all that kind of thing, but it's not in the help.

The help describes the documentation. Much in the same way, when we're documenting GIS software, we shouldn't document GIS theory, right? GIS fundamental idea, and sometimes we do. This is particularly true in the case of this tool that I showed you, the processing framework, all the tools and all the algorithms for analysis

that we have in there. There's an ongoing fight in the community. It's like, we have to document that this way. It's like, no, not that way. I mean, we should document the software, not document all the stuff about what this means. And I can go back to the example of the geostatistical analyst, right? And imagine that we have a slope algorithm

in the processing toolbox or in any other software, right? And it's an algorithm that takes an elevation layer and generates an output layer. How should we document that? But the good thing to do is not to add anything about a slope or about formalizer stuff. It's just document the purely software stuff, right? In this case, like values must be in the same unit

as the layer cell size. That is something particular of that implementation of the algorithm, right? In other cases, the algorithm might assume that the elevation is in feet or is in meter. That is something that the user, even if he's a real expert on terrain analysis, cannot figure out. So we have to document that, right? But there's no need for extra explanation.

The same with the cell size. Cells are assumed to be square. Well, that doesn't have to be like that. Some other software might support raster layers with different cell sizes in the north, south, or east-west directions, right? But our software doesn't. So we document that to make sure that the user understand the limitations of the algorithm, et cetera.

But we don't add any theoretical stuff, right? Go back to the geostatistical stuff. Maybe you've heard about this Kriging technique. It's a geostatistical technique. People use it, people like it. It's a great interpolator, blah, blah, blah, blah, but it's a complex one. You need to know stuff, right? Let's say that the same documentation

or same structure, right? The inputs for those algorithm. Well, we need points to interpolate. We need layers to use. And then we need those parameters to give a value for range, nugget, and seal. Pretty common question that I find in the mailing list or stuff about this is, what does that mean? That should be documented.

Range, nugget, and seal, right? No, if you don't understand what that is, that means that you have zero knowledge of geostatistics or Kriging. Then you're not in the possession to use that algorithm. You need to study more. Not now, but you need maybe weeks or months to understand this is a complex technique, right? And if I explain that to you in the documentation,

you're not gonna understand everything that you need to understand about geostatistics and interpolation, right? So I don't believe that has to be documented. And if we go back to the case of the S3 documentation, the geostatistical analyst, you have something like this. This documentation is good, like really well formatted, really well written.

But in the end, how Kriging works, that is like two, three pages of text. Not more than that. What happens? You go there, and this is more like a tips and tricks for, you know, I get just the minimum information to know what I have to enter in one of the fields, not really understand what is going on. And I believe that now I know about Kriging,

and this is absolutely not true, right? If you just read that, you basically have a little trick to use the software, but you don't understand what you're doing. What do we have to do? That means we don't have to document at all. Yeah, we have to document the software. We have to document the software things, right? Like the things that are of the software itself.

And then for the theory, we don't have to document, we have to put people towards something like that. This is what they need. Not two pages in a help file. You read the book like that, you learn, and then you go to the software. And the issues with the software, the particular stuff with the software, that is documented in the help, right? This is the good way of having a good user to understand the interpolation he's doing,

and that in the end guarantees that the result that he's getting from that interpolation is gonna be correct, right? I know it's not the easy way. It's easier to read one page and believe that you know everything that read 400 pages, right? But I believe that this is what we should try to do if we are trying to educate people through our software

or through the documentation of the software in this case, right? Another thing that we do is just not in the community, not the software, not the documentation, but this interaction that we do, mailing list, forums, we help other people.

What do we propose? Let's not have so much on the forums. Again, this is a provocative way. I'm not saying that we should not help. We should help. This is really useful. But we should think about, just in the case of documentation, we should think a little bit better about what we do, how we try to help people, the advice that we provide on a forum

or on a mailing list. And just like I had the golden rule, I said, in the case of documentation, documentation is about the software. While the software mailing lists are about the software. And I think we should discuss the software stuff, right? Not start discussing those things because we end up in shallow discussions about the statistics algorithms or things like that.

But in the end, we are not helping other people, right? A typical thing that we see, and this is normal because we are like that, not people, but someone comes to the help of some software, like in this case, let's say, this Kriging algorithm. Oh, it's not documented. And I don't understand what this is, right?

Let's go to mailing lists. Hey, I'm using this algorithm. Can anyone help me? I don't understand the meaning of range, nugget, and silt, what's that? And maybe no one answers. Maybe someone correctly says, like I'm saying here, oh, if you don't understand that, why don't you try a simpler interpolation algorithm or read about Kriging and then come back, right?

That's like a correct kind of answer, like putting that person in the correct direction so he or she can learn from the book or whatever. But then there's always someone who says, oh, I used that algorithm. I was in the same case as you one month ago. I entered value zero, one, and two, and it worked. And that other person goes there, tries.

The software works. You end up having a raster layer and you think that is correct, right? That is not a way of helping people. You give like a minor trick to make the software work, but you're not actually making people understand what they're doing, right? So this is, it's good to be, you know,

have yourself, you know, help someone and see yourself, so others see yourself in the community helping other people, right? But let's provide useful advice, like sound advice, not just tricks like that, but you know, let's provide advice that actually make people advance towards being like, you know, better GIS professionals, right?

Another thing that's important to know is this, beware of gamification. I'm sure that you know that, you know platforms like Stack Exchange, there's GIS.StackExchange, sort of forum kind of thing. You post questions, people reply, and you get points and you get batches, like the silver bats and the golden bats, right? So it's good because you believe it's a game, right?

There's the idea of the gamification, and you play the game more, right? People answer more in that kind of platform that is you don't get anything, right? If it's just, you know, replying. But that is somehow dangerous because, you know, people see a question and maybe a question

that they would not answer to in a normal case, but just to get some extra point, oh, yeah, I know how to do that. And they provide very poor responses in many cases, just to, you know, because they think that the main goal of that is to get points, right? And it's not. The main goal is to help other people, to provide good advice. And then, you know, you get points

and that makes it more fun, and then can make it better, right? And this is not something that, you know, my personal opinion is well-known fact that, you know, people try to get more points in this gamification stuff, and then just try to, you know, reply where they should not be replying. And you know that there are mechanisms then to downvote replies,

so they are marked as incorrect. But we all know that some users, if they are desperate about trying to do something, they might try even the wrong replies. Oh, yeah, let's try this. And it might work. Oh, it worked for me, even if it's wrong, right? Even if it leads you in the wrong direction, right? So beware of that.

And just like I said, let's work on mailing lists. Let's collaborate with people in forums, but let's do it the right way. Just like, you know, providing sound advice. If not, better to collaborate less on this, right? So as a summary of all that I've been saying, I think that we have to make the difference

between users and professionals, right? So I'm not saying we have to create better JS users. Like, what a user is something, is someone that actually just can use a server place with a software or a computer, right? I think we should focus, or our goal should be to create better JS professionals, which is someone who understands what it's doing,

not just a user. The idea of a user is vague and it's not per se good, right? To have a good user. We should try to get good professionals, actually people that understand. You know, hopefully with this small ideas that I've been describing here, we can go in that direction. And the other one is, I've said, me versus the others.

We usually try to, that user or that person that is using the software, we try to make him or her feel good about that. I know what I'm doing, it's me, I'm a good professional. And it's not like that. It shouldn't be yourself who confirms that you are a good professional. It's everyone around you, right?

The others, right? So as I was saying in the case of the map, it's not that you have to be happy with the map you create. The people around you that see that map, that uses that map, they have to be correct. They have to be happy with that. So they are the ones that actually give you that label of being a JS professional, right? So this is where we try to focus. Not just to keep our users happy,

make them believe that they know how to use the software or they understand that, not themselves, but the others, right? To try to create good professionals that make other people happy with their work, right? So this is what I think that we should try to do and I say doing that by, of course,

writing books or doing training, but also through all the things that we do in the community. Developing software, writing documentation, or participating in forums and mailing lists, all the things that I've been saying. I think this is what we have to do and hopefully we will have better JS professionals and a better JS community which has more knowledge

and it's better prepared to solve the problems that we're doing in JS. Thank you. Thank you, Vitor.

Thank you very much. We can, we have time for two or three questions. Not from users, just from professionals. Yes, Maria, Rui, can you come here?

Hi, this is not a question from me, but from Twitter because I have been tweeting and people are a bit,

they don't understand the talk because they haven't seen it, but they made a good question. If we start doing the user interfaces more complex that may scare users to start using our software and may go to another software that maybe it's not open source or maybe it's,

so how do you see this balancing? Maybe we should try to document a lot the easy functionality and then leave like a hole for the complex? Yeah, I mean, it's a good question. Yeah, definitely, we do, I mean, I understand saying like we have to do, so what is difficult to use is just not have that

as the main goal, right? But in the end, if we finish, if we end up having software that is more difficult to use, let's say a proprietary solution that doesn't share these ideas and it's trying to just make it like very, very easy. Yeah, and it's like users are probably going to move, but as I said, we are not just working on the only,

the way of the tools that we have to teach our users or make them learn, it's not just the software. So at the same time, we should teach them like that, maybe teach them that the easy solution is not the best one, right? So to avoid them going to that way, like, oh, so let's not just teach them yes,

but teach them that complexity in some cases is needed or that having a very easy wizard to go next, next, next is not per se a good thing. So I guess that's like the way probably we can do that. But that's true, people are lazy, people just have, they have a tight schedule so they need something that they don't have to study

anything, just go click, click and get some results. So the world is more complex than that. I don't see a way of that. Ideally, like both the proprietary software and the open source software and all the software should focus that and let's try not to create that kind of software that gives you false belief that you understand how things work.

But that's not gonna happen. That's being too naive, but yeah. Great presentation, Victor. Thank you.

In the past, a proprietary software vendor had three versions of their product. And one of them enabled you to make a simple map and do some stuff with the map. And then the next one and the next one unlocked more complex functionality.

And I absolutely agree with you that we need to have better professionals. And when you're doing complex stuff, you need to understand the theory behind that stuff before you start using the tools.

But at the other end of the spectrum, we've got a million people using a desktop product that we've produced and probably 950,000 of them are doing fairly simple things with that product. And somehow we need to find a way maybe

by having an advanced version or maybe by having everything in one package but with different interfaces that you unlock as you know what you're doing. Because these 950,000 users who are using our product to make maps, some of them are making

some really good maps with that. If what you need to do is visualize four layers of data and then do some beautiful cartography on that, then maybe you can do that without understanding geostatistics and creaking. Right, yeah, I mean, I like that idea of having different versions like that.

But for example, in the case, I don't know exactly how to put that, but in the case you were saying like creating beautiful maps, right. Let's say you get a software like QGIS and it's kinda easy to do the symbology. The interface is pretty good. But it doesn't have like, let's say, extra functionality to help you pick up colors, right,

for instance, right. So this is a question that I usually like to do when I do some presentations. Like how many people here has created a map? And everyone says me. And it's like how many people here has read a book about cartography, about selecting colors, about what is a visual variable? And it's not even half of the people does that, right. So this is the kind of thing that,

the interface per se, it's easy, right. It's like, you know, it has to be easy, like creating the symbology. But if we try to make it easier, like, you know, by default it generates some, you know, it picks up the colors and makes it, that's not the good way because anyone that tries to create a map should at least have some knowledge of how to create a map, right. How to, you know, the visual variables,

like visual language and symbology and all that. Most of the people don't have that. So some things are easy like they are because they cannot be really complex, like the symbology. But we shouldn't try to make them even simpler or even more comfortable to use just because some people might feel better. Which is like, we should guarantee,

and I don't know how to do that, but we should guarantee that anyone that tries to open a raster or a vector layer and set a symbology, which is super simple, anyone doing that should have some background on cartography and how to do that. That's my ideal situation, right, because otherwise it's pretty easy to just, you know, open layer colors

and just start picking up colors and then in the end might end up with someone that is, yeah, it looks great but it's not so great from the point of view of cartography. So, you know, in general, like, the idea is to try to force people or at least to help people to get more knowledge, to read more, to learn more, and try to do it with the software,

but definitely not gonna be possible all the time, right? Another question concerning your documentation was, it's a bit misleading from my viewpoint what you described because what you were describing was more about not mixing user manual

with other documentation. So I'm wrong when I say this because you were describing input, output, or whatever, but you were saying, I don't want to describe the in and out, behind the buttons or the theory. So you. Yeah, just describe the software stuff. What you would describe as documentation

is not documentation, it's only a subset of documentation, the user manual of the software. I don't understand the question. So, I mean, what I was saying is that the documentation or user manual should be about the software, right? Not tell you things that, like in the case I was just saying, for the question that Steven made,

like, you have to describe the symbology thing, everything in detail, but you shouldn't add any stuff in there about how to make a group map, right? About visual variables, about visual language, about all that, that doesn't belong in there. You are assumed to know that already. Yeah, but it's documentation, but outside of a software scope.

You want the software usage scope itself. Right, yes, it's the documentation outside of the usage. Yeah, that's what I was saying. Presentation. I just had a small comment. I was a bit concerned when you said

that we should help people less on forums. And, you know, I'm speaking from perspective of a person whose daily bread is going through Stack Overflow, GitHub, and Google Groups in search of examples or advice. And you would be surprised how much of my knowledge

comes from very small comments that just fill, you know, like small gap in my knowledge. And I get an idea how things work and how they were designed. So I'd like to finish this with a quote I heard from one British researcher, it was a name I cannot remember, but he said, your noise is my sino.

Thank you. Yeah, it's not that I was saying you should have less. You should have more if you can, but not try to help just because you want to help. You were saying like a lot of your knowledge come from small comments. And that's good because those small comments, if they made you learn, those are good. I wouldn't say it's like let's keep those comments,

those small advices, because they are useful. Let's not do other advices that we just do to get points on a gamificated platform, things like that, you know. Like the example that I was saying, like people, hey, I cannot use that. Oh, put that value and it will work. You can see a lot of things like that

in the stacks changed. You can see a lot of comments like that. Those might be small or might be long, but they're not useful, they're not correct. What I was suggesting is to just keep the useful ones, like the ones that you say you've learned from, keep those ones. Let's try to help more, of course. We have to help more the people in the forums and mailing list, but with good advice,

with advice that is useful and that helps you by reading those little comments, you have become a better GS professional. But someone reading bad advice might not become a GS professional, might become someone that thinks that it's a good user, but in the end, doesn't understand what it's doing. So that's the thing that I was saying.

Let's try to avoid that. Thank you, Victor, for your great presentation. I think you made some very good advice, some very valuable advice. But as we talked in other keynotes also,

OSGEO is a community and there are different perspectives and different groups, it's an ecosystem. And you gave the advice from the perspective of developers, and I think that is very valuable. I think the opportunity is that in the community

there are other people that could focus on other things. And if I may summarize your keynote in one sentence, it should be focus on your strengths and do it from your perspective. And together we can create great software

and we can create great documentation. We can help people to become GS experts if they want. And we can do that by providing the open programs, educational programs, we have GEOforALL to do that. So if everybody focuses on his strengths and we understand each other,

then we can together create great things. Thank you. Yeah, that's definitely, like what you're saying, focus on what you know really well and help on that. That's part of what I was saying. If you know something, if your knowledge about something is shallow and you don't really understand that, don't try to help other people with that. Or don't try to document that because you might think

it's useful for you that you're not someone who knows this really well. If you know the software really well, document the software, but don't document other stuff. Even if you know that, you can assume that other people are going to know that. So definitely, I mean, whatever you do, do it with knowledge. If you are a developer and helping other developers,

help them because you know that. But if you don't know the software hard, it's used, don't help them on that. So yeah, I clearly agree with what you're saying. Cool, so thank you. That was an excellent way to finish this session. Thank you once more, Victor.