Transforming for the Future: A Swiss University Success Story
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 66 | |
| Author | ||
| License | CC Attribution 3.0 Germany: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/54063 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language | ||
| Production Year | 2016 |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
MassSinguläres IntegralStrategy gameTelecommunicationImplementationNumberContent management systemLibrary catalogHuman migrationAiry functionBeer steinCore dumpMaxima and minimaProjective planeRevision controlWebsiteBasis <Mathematik>Web 2.0Data structureWave packetUniverse (mathematics)Content (media)Perspective (visual)DampingLevel (video gaming)InformationComputer architectureFront and back endsHeegaard splittingServer (computing)Row (database)Software developerNumberStrategy gameHuman migrationArtistic renderingWeb pageTemplate (C++)Performance appraisalMultiplication signCore dumpGame controllerPhotographic mosaicProcess (computing)File archiverLanding pageRepresentational state transferStudent's t-testText editorFlow separationLetterpress printingInterface (computing)ApproximationComputer animation
05:37
ImplementationStrategy gameTelecommunicationGUI widgetInformationInternet forumRhombusCategory of beingFormal grammarFile formatRule of inferenceUniform resource locatorCopyright infringementMaxima and minimaPlane (geometry)MaizeDisintegrationInterior (topology)Newton's law of universal gravitationExecution unitFront and back endsWeb browserLie groupText editorOpen sourceTouchscreenFluid staticsWeb pageSet (mathematics)Landing pageWindows RegistryParameter (computer programming)Function (mathematics)Ocean currentDebuggerWeb 2.0Default (computer science)Pattern languageProxy serverElement (mathematics)Row (database)CodeDatabaseDemo (music)Projective planeWritingWebsiteGUI widgetContent (media)Module (mathematics)Uniform resource locatorMiniDiscTelecommunicationComplex (psychology)Special unitary groupEndliche ModelltheorieMereologyGame controllerComputer animation
11:07
CodeNewton's law of universal gravitationStrategy gameTelecommunicationImplementationBeer steinFluid staticsArtistic renderingImplementationSoftware maintenanceSoftware developerWrapper (data mining)Social classData structureServer (computing)Power (physics)GUI widgetMessage passingCanonical ensembleFront and back endsCASE <Informatik>Proxy serverVirtual machineVirtual realityConfiguration spaceData storage deviceCache (computing)Software testingBefehlsprozessorElectronic mailing listContent (media)Moment (mathematics)Bit rateCore dumpWeb 2.0Heegaard splittingTorusWeb pageTwitterCodeTemplate (C++)Row (database)Function (mathematics)MereologyTesselationArchaeological field surveyComputer animation
Transcript: English(auto-generated)
00:04
I want to talk about our relaunch project of our main website, www.finvi.ch. And it's a university in Switzerland. And as everyone else, we are struggling with a similar situation.
00:24
We have an external design and want to integrate it with Blown, with the rich Blown editing interface. And I want to give you some insights of the project, the process of development and the tools we developed to cope with the situation.
00:49
And actually, Blown empowered us to do really good stuff and really build complex scenarios very quick.
01:03
So about the university itself, here are some numbers. We have approximately 10,000 students. We had in our old website, we had 400 editors. We stripped it down to, or tried to strip it down to 40, which is easier to support for us.
01:27
It's nine departments and they are spread over for Swiss Canton, so it's in several places. My job involves a lot of traveling from one place to the other. In the old site, we had 118,000 records approximately.
01:50
It was used for an archive. Nobody wanted to lead anything. We want to get rid of this. We want to make it leaner, a new site. And we are a long-term user of Blown. We've used it since 2006.
02:05
And we started with version 2. Quick question. So your old website was blown, too? Yes. So all the websites were blown. We did all the steps, 2.5, 3, and the new one, 4, and now it's going to be 5.
02:23
So the basis for the project was the web strategy. And here I listed some cornerstones of the web strategy. People working in universities are probably familiar with this. They are all kind of the same.
02:43
When the first websites, not the first websites, in the 2000-ish websites, the universities mirrored their internal structure. They had a landing page for every department and institute. And now they want to get rid of this and to make it more
03:03
approachable for people coming to the university for studying purposes, for training purposes, for research. And we want to do that as well. And therefore, we want to drastically improve the user experience. Like no one else, others, we decided to do a big bang release, which means we do no content migration
03:29
but start from scratch with the content, with the layout, a new CMS, with the new major version of the CMS. So everything set to zero, which gives major problems because you don't know where to start, really.
03:46
And as I said, it involves no content migration. So what we decided from the development perspective, we decided we want to go design first. So this is the major cornerstone and everything, the content and builds around that and the information architecture.
04:06
So the design was really the first cornerstone. Another cornerstone for the development was the split of frontend and backend. This is what the guys doing blown server and REST API are bringing to the next level.
04:30
We couldn't wait for that. We looked into it. We had performance problem at this stage without server-side rendering because if you do the naked REST API and inject it into a static page, the page takes quite some time until it's fully there.
04:48
Now with the new versions of Angular 2 and React server-side rendering is possible. So it might get easier, but we do the rendering of the templates. We do it on the server side. We did some evaluation and decided to go for blown 5 and use Mosaic.
05:05
Recently switched to Mosaic 2 and we're very, very happy with it. So thanks for all working on that on the lib6 print. And another strategy was stay close to the core to make future upgrades easier.
05:24
So here I brought you a picture of our project setup. As you see, it's a very complex scenario as the university itself is complex. The project itself was two and we had several teams. Some of them were internal, some of them were external.
05:42
We had diverse tools we used for communication and for storing content. So and therefore we developed a communication module. And again, we orientated this communication model on the layout, on the design.
06:04
And what we did, we took the, we take the layout of the page. This is actually the new layout of the site and split it into parts. And we call this part widgets. And every widget has a name and a number.
06:25
And through all this complex people set up, working with the, in the project, know exactly what we're talking about when we talk about WE 007, that's the navigation widget.
06:48
So this is the backend. If you use blown, this looks familiar. This is the Barcelona theme. So it's basically the same page without the teaser if you switch to the backend.
07:05
Nowadays, WYSIWYG is not a major issue anymore. Or it is a major issue because there are so many devices and so many browsers you have to deal with. It would be a lie to say what the editor sees on his screen will be representing that what the user says.
07:25
Because you actually don't know this. So, and how did we achieve this? Here is the code we used to this. There is a hidden feature of, in blown up theming, which is called the theming policy.
07:45
Who knows of the theming policy? I suspect so. I think it's, I don't know if it's documented, but we found out. Basically the theming policy, what it does, it takes the, from the control panel, the setting and applies it in the registry.
08:07
And it uses the parameters set in the control panel for stuff doing with the also. And what we did is we overwrite two methods.
08:23
It's the get currency and get settings. And we have a method, the frontend check. And we check for a pattern in the URL. This is the WebCMS. If WebCMS is in the URL, we go to the backend.
08:40
And if it's not, we go to the frontend, which is basically the one we selected in the control panel. And here's the BaselNet. Same thing as the settings. Here we needed a little trick because in the default settings, there is a records proxy element.
09:04
And this record proxy element writes to the database. And so, and it's cached. So we need this no write records proxy, which is basically a dictionary which is stored not in a database. And we return this parameters on the fly when this method is called.
09:28
And this helps us to split the frontend from the backend when we need it. So I'll give you a short demo of the tool we used for the frontend design.
09:43
It's called Estatico and it's open source. And it was developed by the agency which supported us.
10:12
So this is what it looks like. So the frontend designers, they do builds on every commit for the frontend design.
10:25
And what it puts out is a preview and it's basically a whole set of HTML templates, CSS, JavaScript is all in place. And this was actually very good to show to the people before we implemented in Plone.
10:43
So we could give it to our stakeholders and say, look, here the bachelor landing page will look like this. And they could here see it, all is working, all is in place. So the navigation, all this dummy data, of course, with static dummy data.
11:06
But they could look at it and say, OK, this is what I want. Here is all the accordions, all is working because it's all JavaScript. And then before we implemented in Plone, they could do the check and say, OK, yes, that's what it wants.
11:24
And all this are split in the widgets. T is a widget we show.
11:41
This is one part of the page. So all these pages are composed of these widgets. And we see on the widget page, we see the preview, how it looks like with some dummy data. We see the code, which is actually a handlebars template. Handlebars is a very popular templating or I don't know if it's popular.
12:02
They used it. They told us it was popular. I didn't know it before. And we have some dummy data, which is basically a JSON record. And what we do, we copy this output of the template and this dummy data into our Python structure,
12:30
which is, since we use Mosaic, which is tiles. And as I said, we do the server-side rendering.
12:46
And to make this happen, we needed to render this handlebars on the server. And fortunately, there is a Python implementation of this handlebars. It's called PyPass or PyPass 3.
13:00
I think it was developed by Canonical. It was then abandoned. But now it has a maintainer again. And we wrote a blown wrapper collective handlebars, which provides us with some basic classes. And all we have to do is to override this get contents and return the JSON structure we have in the static code.
13:32
And we fetch the data from blown. In this case, we get it from a tile configuration.
13:45
But there are other use cases that are scenarios. Sometimes it's content listings. And sometimes it's just static content. So it's different. But the good thing about this, we just copy and paste in the first place the dummy data we get from our design agency here.
14:08
And when it drops out by the agency and we have it in blown, it's a matter of minutes. And people were really impressed of the speed of the development. Because the moment they saw the design, they could immediately play with it with blown.
14:26
And then we iterated to replace this static data like this with data we get from blown. And at the end, I want to share some performance tips we found.
14:45
It's basically the same with everything. We use rel storage, which gave us some increase in performance. We make heavy use of memcached on two layers. We use it for the rel storage as a cache proxy.
15:00
And we use it for the RAM cache. What we discovered, it's important to have a CPU with high clock rate. We used to have a one-size-fits-all virtual machine, which had many cores but not so high clock rate. And we exchanged, we now have a dedicated server in our virtual environment with a high clock rate and not so much cores.
15:27
Which is far more efficient for our use case. And the third one is, I wonder why it isn't more popular and more documented and teached. The biggest advantage was by delivering all the static resources.
15:47
Also for the backend, also for Baselnetter through the Apache web server. So we have our web server catching all the plus plus resources. And it delivered it immediately. So the backend isn't hit and this gave us the most performance improvements.
16:10
We've all seen this page help us improve. Please feel the contact survey. And if you have any questions, you can reach me on Twitter or on GitHub or you can talk to me.
16:23
Thank you.
Recommendations
Series of 55 media