WEBVTT 00:00.000 --> 00:12.060 So, in this talk, I'm going to get you into how starting from a generic and agnostic 00:12.060 --> 00:18.480 weak UI that you can play everywhere, we end up with an extension that you can start 00:18.480 --> 00:23.000 on your next instance in one click. 00:23.000 --> 00:28.560 So first I'm working for an explique size, it's a French company that is specialized in 00:28.560 --> 00:37.520 knowledge management systems, it's something that the company created in 24 or 24 years 00:37.520 --> 00:44.120 ago, we are 75 years old in the room, so we are, of course, now for explique, but also 00:44.120 --> 00:52.160 for grip at the internal encrypted alternative to Google Drive. 00:52.160 --> 00:57.960 Everything we do is 100% open source, on based on international communities that 00:57.960 --> 01:04.640 can contribute on for living, we are doing super training, consulting, hosting in the 01:04.640 --> 01:05.640 EU. 01:05.640 --> 01:11.640 So, I'm Manuel, the take-league of crystal, but also a car contributor to eggswiki, I have 01:11.640 --> 01:20.040 listed some of the closed contributors of the crystal projects going from RCO and CTO to 01:20.040 --> 01:25.600 products on a UI designer, and of course, once again, we are trying to involve the communities 01:25.600 --> 01:34.680 or your feedbacks very welcome, and so let's go into what is crystal exactly. 01:34.680 --> 01:45.360 So crystal is a new, on the modeling UI for which is at love, it's been funded by with 01:45.360 --> 01:56.040 this help of BPI friends, why did we do yet another UI for which we went to the conclusion 01:56.040 --> 02:04.480 that explique is 20 years old, there is this old stack of layers of jQuery, prototype 02:04.480 --> 02:12.160 JS, required JS, so it was starting to age a bit on was like limiting, so we decided to start 02:12.160 --> 02:18.480 a fresh, a front scratch, selecting quickly view, type script, a guide for building the 02:18.480 --> 02:27.160 components in address scripts on using native ES modules instead of having to use 02:27.160 --> 02:34.800 re-create JS which is somewhat deprecated now, it's not only like the question of having 02:34.800 --> 02:41.680 your fresh technical stack, but also the opportunity to experiment more with offline mode 02:41.680 --> 02:50.040 for instance, real-time collaboration, in explique for instance, it's possible to edit 02:50.040 --> 02:56.360 collaboratively the content of the document, but for instance, if someone is adding a command 02:56.360 --> 03:02.480 to a page, it's not live, you have to refresh on navigate to another page to see the result 03:02.480 --> 03:08.080 of the same thing is true for the notification, so starting from scratch it's possibility 03:08.080 --> 03:20.560 to do that add one, so one specificity of crystal is that it can connect to any source 03:20.560 --> 03:29.000 of knowledge, so of course the main source for me working at xwiki is to get pages, content 03:29.000 --> 03:38.880 commands attachments from xwiki, but it's also possible to get them from say a GitHub repository 03:38.880 --> 03:45.400 or to your local 5c system or even on this it's going to be the topic of this talk, so you 03:45.400 --> 03:54.680 are next-cloud drive, another specific crystal is that it's built to be distributed in 03:54.680 --> 04:01.680 various ways, it can be directly embedded inside a web service, which is going to be the case 04:01.680 --> 04:08.440 for next-cloud, but it can also be on its own domain, on connecting to different free mode 04:08.440 --> 04:15.000 sources of free case, so you can possibly have one main, on three point where you have several 04:15.000 --> 04:20.840 configuration to connect to one xwiki, one next cloud, a suitable repository is on all of 04:20.840 --> 04:27.080 them like displayed in the same UI on the possibility to switch easily from one to the other 04:27.080 --> 04:33.640 store your notifications in the central place, and finally you can also do the same but with 04:33.640 --> 04:39.080 desktop application when in this case you can also access your 5c system which is obviously 04:39.080 --> 04:48.680 not possible from the bottom, on a last point that is going to be important is that we want 04:48.760 --> 04:55.640 to be able to adapt crystal to the place, the system in which it is embedded and you want also 04:55.640 --> 05:04.920 it to look like your system, so if you integrate it into your company, you want to be able 05:04.920 --> 05:12.680 to adapt all the appearance to your UI elements library, but you also don't want to 05:12.920 --> 05:18.120 rewrite all of the UI every time we switch to another system, so what we did is to define 05:19.640 --> 05:26.520 TypeScript signature of all the UI elements you are allowed to use to build interfaces, 05:29.240 --> 05:36.520 once you are developing a UI, you are advised to only use those since they are 05:37.480 --> 05:43.960 type defined with TypeScript, you have auto suggestions and for instance if what we picked once again 05:43.960 --> 05:51.000 block notes that was presented just before, there is a navigation and a language of attachments, 05:51.000 --> 05:59.560 history, but one important point is that since each backend doesn't have the same capabilities, 05:59.880 --> 06:05.880 the UI is automatically adapting to what the source can do, for instance if you are connected 06:06.760 --> 06:13.240 to a folder on your 5c system, there is my default non-ocean of fine history, 06:13.240 --> 06:19.480 is the accessible, so in this case all the notions of history are hidden from the UI, 06:19.480 --> 06:24.920 you have the tab to access all the versions of your 5c instance, on other developer, 06:25.880 --> 06:31.400 you have basically nothing to do, you did not implement the history, this story is not there. 06:34.120 --> 06:42.120 And so now the most important point of this presentation, first of all, inside the next one, 06:42.120 --> 06:48.360 so the first thing that motivates us to do this extension is that I believe 06:48.680 --> 06:58.600 everybody knows next story, so it was a very good paper tagged for us, and they have this 06:58.600 --> 07:08.840 very nice extension mechanism where anyone can publish extensions quite easily, so it was a good 07:08.840 --> 07:17.960 simple as I also looked at alternative to not publish yet another thing that was already there, 07:19.160 --> 07:26.520 I found Brumimo, not some collectives that are existing extensions that are allowing users 07:26.520 --> 07:36.440 to write, not I also found Dokewiki, but sadly I did not manage to make it work, 07:38.600 --> 07:47.800 so again I can't make it part of this contained attachment inside Wiki, 07:48.280 --> 07:57.960 the same thing for links, because if you are editing for instance with notes you can select 07:57.960 --> 08:05.080 attachments, but all the files of your next plot are proposed, but what you want to do in writing 08:05.080 --> 08:12.440 a Wiki is to have the attachments of Wiki, only on not the other one, but all the files you have shared 08:12.440 --> 08:21.560 with others and so on, you have to make them stay contained inside your Wiki, the last important 08:21.560 --> 08:29.560 point is to be able to save to your drive, to your next to drive in a format that is understandable, 08:30.440 --> 08:37.320 by next plot even outside of Pristar, the idea is let's say at some point Pristar is not maintained, 08:37.400 --> 08:44.920 you remove it, you still have all your content of Wiki, as my done files inside your next plot, 08:44.920 --> 08:50.760 you can still operate them, you can still navigate, you just don't have the nice Wiki UI around it, 08:50.760 --> 08:55.720 but you still have your content is not closed, or you can migrate it the way you want, 08:57.000 --> 09:02.760 and also I did, as a bonus, the notion of page templates, because I found it in the 09:02.760 --> 09:09.400 collective application, and I found it nice on shamanas for now we don't spot it, but it would 09:09.400 --> 09:14.600 be interesting, for instance, actually also have this concept, so it would be easily verified inside 09:14.600 --> 09:25.320 Pristar on, then be applied on, arbitrary sources, so yeah, Brumamo is the most limited one, 09:25.320 --> 09:33.480 I would say they have a basic editor, just a notion of list of notes on those notes are not saved 09:33.480 --> 09:38.920 into the drive, they are probably starting some database, but then they are not easily accessible 09:38.920 --> 09:49.080 from the drive, notes on collectives, both saved, they are content inside my done, in a standard 09:49.080 --> 09:53.880 format, I believe the edge has the same editor provided from the next plot to be confirmed, 09:56.120 --> 10:05.640 on Soda's Pristar, on only collectives, I wrote to nest pages in an arbitrary, 10:05.640 --> 10:11.720 at an arbitrary depth, notes only I wrote to have groups on pages inside the group, but not 10:11.800 --> 10:17.960 deeper than that, so yeah, in conclusion, it was not a waste to have Pristar as the yet another 10:17.960 --> 10:23.160 extension, because I believe it's adding some features that are not available through other 10:23.160 --> 10:32.040 extensions, I'm going to quickly summarize the steps we had to follow in other two embed 10:32.040 --> 10:39.640 crystal inside next plot, so the first step was to be able to access the content of the drive, 10:41.240 --> 10:46.840 we did that even before considering the extension, like about one or two years ago, 10:47.480 --> 10:55.640 through WebDive and since it was remote connection, we had to deal with tokens or since 10:55.640 --> 11:01.320 one, but in the case of the crystal extension, you are directly embedded inside your next plot 11:01.320 --> 11:08.280 instance, so if the user is connected to next plot, Pristar is also connected, so it's easy to 11:08.280 --> 11:13.480 handle authentication, since you have basically nothing to do, which is quite convenient. 11:15.800 --> 11:23.480 Here you can see the result of the use of the next plot design system implementation, 11:24.440 --> 11:29.160 you can see the red premise, the next plot side, the navigation field, so the buttons, 11:30.200 --> 11:35.880 the tabs on the path of the spin shot better, also style, last, like next plot tabs, so it's 11:35.880 --> 11:45.480 basically a next plot UI for four weeks, to do so, we only add to develop this next plot UI extensions, 11:46.840 --> 11:52.440 the rest of the cut of Pristar is not impacted by this, if you need to adapt, 11:52.520 --> 11:57.640 Pristar too, and as a context, it's also the same, you develop this specific extension, 11:58.760 --> 12:03.960 specifically use it, it's supposed to adapt automatically. 12:06.520 --> 12:11.560 One last point, at some point, of course, we had to publish the extension to the next plot 12:11.560 --> 12:19.320 store to make it available to all of you, and just wanted to say that it was a pleasant and 12:19.400 --> 12:26.520 well documented experience, it just for us documentation, and it's working, which is very cool, 12:27.320 --> 12:32.360 and it was easily automated with GitHub actions, on the actually found out this morning, 12:32.360 --> 12:39.480 that it's also documented, but I missed that, so I really did work myself, which was quite straightforward. 12:40.360 --> 12:49.320 Now, with my adding a tag, once the card is ready, the release is done in a few seconds, it's pretty 12:49.320 --> 12:59.320 cool. On just a few, I guess, one slide on the ipadot use on Pristar since last year, 13:00.280 --> 13:11.000 we worked a lot on the editor, so again, it's blocked not, on what we did is the integration 13:11.000 --> 13:23.240 of Microsoft. Microsoft reusable content that you can easily add to your pages, for instance, 13:23.240 --> 13:29.320 you can use them through the quick actions. They are added to your content, or in what you see, 13:29.320 --> 13:36.600 what you get why, and when you say on being human, you have the same, the same results. Once again, 13:36.600 --> 13:42.760 those are extensions, so if you want to develop a new micro, you can just add a new extension 13:43.640 --> 13:50.920 by adding this new micro extension, this micro gets integrated in the editor, in your view mode, 13:51.880 --> 13:58.680 automatically, those micro can have dynamic content, where looking into implementing 13:58.680 --> 14:04.600 a table of content, for instance, to make it live, so if you add new headings to your pages, 14:04.600 --> 14:12.040 the table of content is refreshed, live, client side, automatically. We're not there yet, but 14:12.040 --> 14:19.880 because we have to get the right bindings, but we're close to it. And so yeah, once again, 14:19.960 --> 14:26.600 everything is done from a single definition, you don't have to write editing content on 14:26.600 --> 14:32.600 your content, you just write once your content of your micro on it's editing, it's have to 14:33.960 --> 14:39.080 the editor or the user view mode, I won't go into the technical details, but if you're free to ask 14:40.440 --> 14:48.120 later. So, not that crystal is super easy to install, you go to your 14:49.000 --> 14:52.600 next plot administration, you look for crystal, you click install, you are done, you have 14:52.600 --> 15:00.840 a week in your tabs of your next one instance, so if you do, we made this form, so please give us 15:00.840 --> 15:06.280 feedback, if you get into the favor, if you see something that is not usable, not accessible, 15:06.280 --> 15:12.440 anything, you feature idea, there is this form, please, if you want to contribute, you are very welcome. 15:13.320 --> 15:21.320 So, yeah, that was it. Next, first of all, inside next one. Thanks. 15:27.320 --> 15:31.720 Okay, thank you very much for what you do, I have a couple of minutes left, can you call your 15:31.720 --> 15:37.480 questions? Now, the question about files, you mentioned that the contract management in the 15:37.480 --> 15:43.560 Wiki, which has an insight, and inside the Wiki, how do you see them, the difference between 15:43.560 --> 15:48.360 I store in the files in next, now that some files are stored in the Wiki, how do you see that 15:48.360 --> 15:52.840 when you see in the next one, the reason files, I can also imagine you think it's messy. 15:53.400 --> 15:58.440 Yeah, okay, so I will repeat the question, so how do we distinguish between 15:58.440 --> 16:05.000 attachments that are part of the Wiki and attachments that are not, so the, there is a route, 16:05.720 --> 16:10.840 the directory, which is a route of your Wiki, on all the content is below this foot, so it's 16:10.840 --> 16:18.440 for instance, dot crystal. So, it's the first, the way to see if it's in the Wiki or not, it's to 16:18.440 --> 16:23.960 know if it's inside this specific folder, but also we are following some strict shirt content 16:23.960 --> 16:32.200 with a convention naming, so it's name of the page dot meta data slash attachments slash the name 16:32.200 --> 16:36.440 of your attachments, so it's, and as a way to, I actually also find it in next mode. 16:36.440 --> 16:41.320 Yes, everything is, okay, yeah, everything is typed in next one. Attachments, 16:41.320 --> 16:45.720 I don't, for the content of the pages, we have a question here. 16:45.720 --> 16:57.880 Okay, so the question is, can I use crystal to show data coming from different sources 16:57.960 --> 17:05.320 at the same time? Currently, you can easily switch from one source to the other, but then you 17:05.320 --> 17:14.360 completely change the context, there is no way to share data between which is, we have plans for that, 17:14.360 --> 17:21.960 we have unified three of pages, possibly to be able to drag on draw pages from one week 17:22.040 --> 17:29.720 to the other, or even maybe to link pages between week is, but it's like, for the way future 17:29.720 --> 17:36.360 world maps. So, the photo question on the attachments in next mode, can you actually make a link 17:36.360 --> 17:43.640 to a next go file that's not in the crystal area? So, the question is, can we make links to files 17:43.720 --> 17:53.240 that are not in the crystal folder? The answer is, technically, yes, but the UI is not proposing 17:53.240 --> 17:58.920 it, currently, but it could be a simple improvement to make it explicit that you are, 17:58.920 --> 18:04.680 or wanting you are going outside of the week, maybe it's going to get you input for that, but 18:04.680 --> 18:14.680 technically possible, yes. 18:28.680 --> 18:34.600 Yes, you, in the week is I know, it needs not universal 18:34.600 --> 18:40.360 but you can have, like, root pages that are themselves containing pages, sub pages are on so on, 18:41.960 --> 18:51.000 on that's what I mean by nested pages. 18:57.640 --> 19:04.440 So, repeating the question is, are we using standard notation for the content of pages? 19:04.760 --> 19:14.200 Yeah, the process we are adapting to the expected format of the source in which we are saving 19:14.200 --> 19:20.040 the content. So, if I am saving Macdon, Macdon is not, you know, a very strict standard, 19:20.040 --> 19:26.680 there is, like, variance based on the context. And when I'm saving a link inside next 19:26.760 --> 19:34.760 instance, it's not the same syntax as when I'm saving a link in Macdon inside, for some reason, 19:34.760 --> 19:40.760 x-week is using double brackets, while next slide is using a single square bracket with the 19:40.760 --> 19:49.080 parentheses on the URL as the specific format with an object number that I have to resolve. 19:49.080 --> 19:56.440 So, the logic is slightly different based on the context. The goal is to always as much as 19:56.760 --> 20:02.840 we can make it work in the standard way of the system. That's why, like, when you save the page 20:02.840 --> 20:09.640 inside next slide, it's also a usable, even without using crystal, if you open it in the standard 20:09.640 --> 20:14.920 editor, the links are working, the UI is the one expected by next slide. And if you would save 20:14.920 --> 20:20.360 this content, it's an execute, it wouldn't work. So, you have to be context aware when 20:20.360 --> 20:27.000 serializing your content in the source. You could get lazy on a standard content, it would be 20:27.000 --> 20:32.760 much easier for developers, but then it would integrate inside the system in which we are 20:32.760 --> 20:35.960 embedding on that's one of the goal of crystal. 20:35.960 --> 20:40.360 The first thing you secure code for the crypto form was wrong there. 20:40.360 --> 20:48.360 Ready? I'm going to fix it in, so you can go back to the web site of first demo, I'll fix it 20:48.360 --> 20:54.360 in some checking, checking that while that's done. 20:54.360 --> 21:02.360 Okay, at one moment, minute, if anybody has any questions, please. 21:02.360 --> 21:07.560 Do you know how migration tools from other cookies? Because I think it's a very good goal 21:07.560 --> 21:11.960 that it always runs on the whole system, but if you don't have to get there, you already have 21:12.920 --> 21:17.720 do we offer migration tools for no, we don't. 21:17.720 --> 21:22.040 Since we are like adapting to the weekly, if you write your connector correctly, 21:22.040 --> 21:27.640 we get access to the data of the source. And then we could imagine to have mechanisms to 21:27.640 --> 21:32.680 convert from one source to the other, but it's not part of the current format. 21:32.680 --> 21:36.040 So I have a question that you've read into the previous one. 21:36.040 --> 21:43.080 If you drop a bunch of bottom files in a folder in the next one, can you then have a 21:43.080 --> 21:47.480 crystal display them as big as in your cookie and then it comes further? 21:47.480 --> 21:52.040 So the question is, if I just open a folder with existing mod on files, will it work? 21:53.160 --> 22:00.440 It depends. I think someone tried with obsidian, it's an obsidian volt, which is basically the same 22:00.520 --> 22:07.800 idea on it was working ish. You have provided some limitations, but you get most of the content back. 22:09.800 --> 22:10.760 No guarantees. 22:13.800 --> 22:19.000 Yeah, by chance, because like, does it recognize the structure? It's just lucky because everybody 22:19.000 --> 22:25.000 is using photosensei for photosensei for those with fights. So it's somehow working by my luck, mostly. 22:26.200 --> 22:26.600 Thanks. 22:26.600 --> 22:28.040 Okay, thanks everyone.