 Good morning, ladies and gentlemen. Nice to have you here. Nice to see all your shiny red faces. One of the most important points, Debian, is to have some kind of good representation to the people outside who are not getting you no Debian. Therefore, it's quite an important task to have some kind of website. It's always documentation where users and developers can find what information they need very fast. However, there are usually some kinds of complaints about not able to finding what they are searching for, not in the correct language, or not easy to navigate, and not really looking. So we have here Frank Lichtenfeld, who will tell us a bit about how we could try to improve our websites. Hopefully, you will give him some feedback, right? Yeah. So basic point about this launch table, as it was titled, would be that I would be interested in your thoughts about the website and that we would like to perhaps discuss, or how much this would be possible here, I don't know, to discuss some questions about the website and to see whether we can find some ideas how we can improve it. So I would like to hear, as perhaps some people from the audience that are interested in, to hear some thoughts about the website and to let's just say, what's your biggest complaint about the website? So who would like to say something about that? Yeah, Joey? It's too hard to find things. There are too many different ways to get from one point to another. That's my biggest complaint. It looks old school. OK, so we have too hard to find some stuff, and it doesn't look pretty or shiny or something like that. Some as, yeah. There's more to looking pretty than just being satisfying for the eye. The aesthetic part is one thing, but there's also other points of making things look right, meaning, for example, to provide visual cues for people that they know where to click, and also for, for example, colorblind people to take them into account. So there are other aspects of the visual appearance of the site than just being aesthetically pleasing. Yeah, so let's repeat it. So we have something on the record. So there's visual appearance and layout. It's not only about looking shiny or looking pretty, but it's also a point of usability so that you have visual hints for the users where he can orientate on and visual appearance is also important for people with some kind of handicap, like colorblindness or something like that, so that the website is also usable for them. Other things? There's a lot of information in Debin available that is currently on home pages of people or people with Debin that a lot of documents have been written in the past. Yeah, OK, so the point was that there are a lot more websites on Debin than only the home page, especially there are many websites from Debin, there are a lot of us on people.debin.org or stuff like that. There are also the whole QA pages and things like that. But it's pretty hard to find links or find any information about them. So one thing would perhaps be to better integrate them or to better make it at least possible to search them or something like that. So yeah, next point. Yeah, one thing with the pages not being available on Debin.org is that it's hard to translate them. Yeah. It's hard to translate everything. OK, the point was the advantage of having information available on www.debin.org is that there is a translation framework for this. So pages that are not there are mostly not translated at all. OK, other things you want to tell us in front? OK, to be a bit more specific about things with the website is, so let's start with the developers' corner. It's the starting website, I guess, for the internet for Debin developers with information for them. So we have a lot of stuff here, a lot of links. But as you can see, the page is quite long and very many links. So even stuff that is linked from here, I often hear. No, I didn't find that. I didn't know that it was there. So what I would be interested in or can talk even a bit about that, how to improve this website. Because many developers have said to me that the Debin website isn't really usable for them. So there are some obvious things to do here, like splitting this website into more, to give the user the chance to actually address what is on the page and to see where to go from here. The question is, do we have other ideas? What would make the Debin website in general more usable for developers or for contributors? Well, I think some parts of the left side of the basic isn't really for the developers' website, because not for the developers, for anyone who wants to take a close look at Debian. Whether it's in the developers, the CD vendors, sponsors, whoever. And the people page is well, I'm not sure if the people page is really of any use. Yeah, so the point was that even many links that are here on the developers' page don't really belong there, because they might be of interest for other people, especially things like Debian organization or things like that. But are somewhat hidden here, yeah. So, and things like the people page where all the developers and all the main package maintainers, additionally, even if they are not developers are listed, is, yeah. It's just the long list of names with package names attached to them. Yeah, not really, I'm sexy. That same. Other thoughts? One thing you do with websites that isn't being done with the Debian website is doing some user analysis first. And make targeted pages. We've been discussing around the table in the container. Who was the target of this page? And apparently what we came out is that it's mainly useful for people who want to become Debian developers. And so they can find all like policy and stuff. But as Debian developers, many, at least around our small table with like four people would like to find, for example, what's in Alfie people page. If you want to go to people.org. Alfie, which is all the links to all the like status page on what you do, your DDCar, my stuff. Possibly like I put my GPG ID or email address in it. Okay, let's see. I'm not used to English. So it's like all those pages that value like if your packages have been built and what's happening and what's its status of the robots and what's the graph or whatever. This is like the things for the bells that you don't find but then you don't want to give them to like new containers because maybe they have no pages. And so maybe splitting by person. And then when you receive a request, you see who's making the request and you add it to the right page. So for the curious, for the press, for the maintenance candidates, for the developers, this sort of range. So the proposal was to do more targeted pages to better split the pages so that you can give different users different pages so that they only find the information they seek and are not overwhelmed with too much information they don't need. So like the DBN developers' corner is many of the stuff is mainly interesting for new maintainers. And some of the stuff, especially links to useful other pages like collected tier, are mainly of interest for deep-end developers. So split the page to give both audiences what they need and have them to bother with the stuff they don't look at and don't need at all. I guess it would also be useful if you could log into the website as a developer and automatically you have selections based on your username packages, stuff like that. Okay, the idea was to give developers, perhaps contributors to the possibility to log into the website so that links to other resources about their packages and about themselves like the DBN developers' packages overview on QA or stuff like that so that they are pre-linked with their username or that they see a list of the packages and things like that. It's curious in my opinion if you're saying, okay, what are the websites that I want to find and reach and what is the path to them? So now just notice that most of the information that goes on the main page, why is this the developers' page? So it means that the main page has just the most important links and it's to the relevant ones and the rest of the links are very unimportant. Okay, he said that he thinks that most of the interesting stuff at all is in the developers' corner so the link on the main page to the developers' corner is just one step too much because you have all important links here. I tend to just create a bit about this one because I think from a user's point of view most links on the developers' corner aren't really useful at all and stuff like where I get my user images or... For example, if you take a look here and say, okay, you're now in one of the subgroups in Debian, like... Let's say it's very women's group, where do we go to? Yeah, so the point was that one thing you can't find on the main page are the different sub-projects like CDDs or the even women things like that and I think that's a valid complaint. I think that would be one point that should be really fixed to give the user of the website more and the idea of how Debian really works and many sub-projects or CDDs or maintainer groups so this isn't reflected on the website at all at the moment so it just looks like... Yeah, I think the whole thing about how to communicate with certain people or where do I find certain groups or certain maintainers isn't really visible on the website at the moment so I will give some people more the chance to say stuff like that and then I would like to go on specific points that were mentioned and ask more specifically so that we can go more into detail. One thing I think about improving the visibility of the sub-project is we have a news section on the whole page that should include the news from the different sub-projects and the main news at the moment. We have news pages for like Debian Med, Debian Edu, Debian Installer. Think about whether those should actually be shown on the front page as well. So you don't look at the news and you see, oh, the last news item is four months old, okay, it's not the moment because we're... sometimes you find that the last news item is half a year old. It doesn't seem like anything is happening. So we're thinking about doing something about that. Okay, so one suggestion here was to... since we have here the last news item on the page where we give some... where the user can find news items but we have a lot more of these news items for example, let's take one of the... yeah, one principle problem. So let's take for example the CVDs. Yeah, there we have... let's take the active one actually. So we have a news item there too but if you don't know about the project, don't... you will find this. And especially some of these might be really interesting to people that don't know the project yet. Like, let's take the last news item although they were made at Defconn 5, okay? So that's... so one suggestion would be to give... to make it possible to include news item from sub pages or even from remote pages since some projects have their own web page that isn't hosted on this server but that could easily be made possible via SSVs or something like that, stuff like that. So to give sub-projects and groups the possibility to include news items on the web page, on the main page. Other general stuff you would like to mention before we go more into detail? If we're showing news, I think we should really look into splitting user news and developer news. Okay, yeah. So the suggestion was if we want to show more news and so then we should think about splitting them into user news and developer news since probably if you show too much items you don't know which are relevant for you and so one could make a list with developer-related news perhaps even include selected posts from developer announcements there would be one idea. On the front page it may be user news but it's hard to find the developer news because that's scattered everywhere on the web site in other places. It's not consolidated that somewhere maybe not on the front page but somewhere the developer's front page focuses on it. Yeah, so this was the suggestion that developer news, if you create such a category you probably don't have to go to the main page for reading but instead to the developer's front page in this, let's say, like this. The pop item here is an example of something that comes from a developer point of view but it's really useful for integers as well. So... Yeah. It's hard to categorize. Maybe it would be a good idea to get recent changes to function to make it dig into all the different sub-projects and create one huge block of all of them. I think such a thing would be helpful. I don't know what you're talking about. The different sub-projects each have more or less their own news section and we could get recent changes to not only look below one directory but below all of these sub-projects and get a collected news section about the sub-projects. I think that's what I was suggesting before and probably just in other words. I think it would be cool to have these ones also as S-feeds. Yeah. There's certainly the possibility to include way more as S-feeds and things like that on the website. There are a few and there are certainly some news sections and things like that that are not covered and that would be interesting for... I think there will never be a speed to have more of a secured alerts at the moment. Yes, that's probably true. It would be cool to just have a better name page of other than linked like get news fly as S-feeds and have a list of all news feeds with the app software as S-feeds. The suggestion here was to create... If you have several S-feeds for different news categories and that you should make one over your page you can see all available ones. So my suggestion... My question would be the thing I guess it came from Farnspok. Do you think it would be useful to be able to log into the website and to make it more interactive and what would you like to have? Is this something you would want and what features would it make attractive to you? That would be my question. I think there are some places that might be nice to make some pre-selection. It's not just that you can just do it with cookies and just say the members are setting for me. Like for example which meal... which meal server do I want to use if you still have this meal that I can elect where to go to and stuff like that. Okay, so he said that perhaps it isn't needed to create a complete login system with all the problems you have with that like maintaining the login information and so on, but to just make it possible at certain points to just like preferences where cookies are similar so that perhaps your Debian login name is in the cookie and so links can be adapted to your needs. What are your thoughts about the login stuff? We can also take a... One first thought I can have about it is a bit more technical maybe. So now everything is in WML and it's quite static and having it kind of dynamic would be like making a CMS or adopting a CMS and whenever you make a new CMS you'll get them so you have to pay attention and so is that a viable alternative and are we allowed to think about possibly switching to some CMS considering also the load? So the question was the whole website infrastructure supports static webpages at the moment so the question was would it be possible to use a CMS instead and should we consider that? The one answer to this is the websites should... Most of the websites especially the things that are interesting for users should be easily mirrorable. So if we want to change the infrastructure of the website I think it's really viable that we still have the possibility to easily create mirrors. I don't know that for really sure I guess with the increase in hardware performance since the creation of the website perhaps is not even that important anymore because one server can handle the load of all the mirrors I don't know that for sure that would have to be investigated but one thing you could do against this would be to select so if you would do for example find that you only really need the CMS for the developer's corner or something like that you could move it to a different house or something like that so that you don't have the conflict yet What would be my question? What do you see as advantages of CMS over the current solution like name example or example use of CMS that isn't possible with the current stuff? Just because we are talking about logging in and having customized pages and unless you want to generate a static version of the developer program for every single developer you need to use a CMS and this changes a lot of the further discussion because we can choose to not consider a CMS now which could maybe be sensible because there's also translation workflow which will be screwed up and then I'm not going to propose grouping things and categorization for the website and whatever because then you can't navigate it or something or if we think about a CMS then a lot of new idea comes out and I don't know what's going to happen on the next half or above but that changes a lot what's going to happen So I personally think that it's not a good idea to think about a CMS now I'm not pushing for it Okay, yeah So the example advantage would be things like let users log in since you have to create some kind of CMS for that and you could really use a real one instead of writing your own but what you also mentioned was that if you choose to use a new infrastructure like that you get a whole bunch of new possibilities and new ideas and so it's the question whether we should discuss this really here because you get whole two different discussions about what is possible or what would you improve now or something like that and let's change the whole infrastructure and then look what we want to improve so there are two very different discussions and it's the question whether we should risk to miss that Yeah Confused, yeah I really want to warn of something because I really think it's very dangerous to believe it's easier if you have a CMS I even think it's more difficult to write web pages because well, SysList is definitely not the best but we are the best in the world possibly to have just the single users but it doesn't mean that we shouldn't have a console but it's even worse, we must have better and we must know better how it should look like in every single combination and currently we have a lot of dynamic pages like the developers over you such as at some place like Q80 they should probably be better implemented here I don't disagree about that but I really don't think that we need a CMS and right now and we have a lot of more important problems that we could be easily solved with the current situation like I would really say it's a long list of links that nobody finds users don't complain that they don't find a link to the Debian installer which is here but of course very important to use us definitely Sasha was asking we often ask questions in user channels in German so, yeah okay, so yeah you want about that if you for example switch to CMS or use CMS additionally to the static web pages you will not only get a whole bunch of new possibilities but also of, yeah new things you have to care about and for example if you have there are never really great pages you have to make sure that if the user chooses something it still makes sense you have new combinations and you have to maintain more content in this regard so that mixing the content still makes sense yeah, and things like that and so the suggestion was to first look what can we fix with the current solution like splitting up developers corner things like that which are easily possible without CMS yeah I think all this discussion leads directly to a very important question which is how do we want to work with the website what are the criteria for splitting up things and how do we want the navigation flow to look like and I think Enrico was onto something very good here he spoke about use cases and the fact is that nobody really knows how people use the website at the moment I think we discussed this on the mailing list also and somebody suggested to look at logs and other things and I suggested that we should try to deduce from the current website the use cases that we are supporting now and look at those and see what we are still missing and after that it will be easier to consider the technical solutions for example to choose between the current system or CMS or something completely new okay, so the suggestion was to really try to analyse what use cases there are for the current website by for example analysing the logs and to learn more about how the users use the website currently so because this will give us a better idea about what things we need to change and what things we need to adapt and it gives us more information about the use cases whether we need really a CMS or if we can implement these things the users want with the current solution to come back to the logins problem I think it might be useful to get the different pages like the QA developer page like idios page about the build use and such which could use some sort of preceding to easily click through and not having to insert your data or the time there I think something that we would include such there is very much linked in the QA developer page already cross-linked to the various other stuff like the testing script and the lintern reports and such but these things I guess need to be incorporated even more and this maybe could be done through a single login page but on the other hand with the lintern pages we already have the list to click through from all the developers so it's not really needed to be a dynamic thing like PHP or whatever to get this thing done so the point was the obvious advantage of the login would be that you can use the other information pages like the divin developers packages overview faster since the pages already know who you are and what are you probably looking for and you can even think about integrating them more into the main website but this doesn't mean really that they have to be dynamic or something like that because let's take the lintern page it's a static page but since you have all the sourcing you probably want it's not really needed to make it dynamic or something like that but only to give you directly the link to the page you want so I think we can take two points from here the question whether we want another infrastructure or an additional infrastructure like a CMS should probably can't discuss here in all the details or at least not in this talk but we should certainly think about that and the other interesting thing is really to try to find out what users want from the web page and how they use that so the basic problem is someone needs to do it so I will start to take that with me and also mention that on the mailing list and discuss it there but if someone has already ideas how to do it or who should do it feel free to contact me and say this to me but I don't think it's needed to do this right now in the audience so where to go from here so are there other things you still have to add to this point are there two questions so generation of one static page per developer per developer is a possible alternative like I log in and I'm redirected to a static page just being pre-generated with all my links so the question was if so the question was if it's an alternative to try to use static pages for now let's say for the log in so you have only one CGI and then you are redirected to static pages again which are pre-generated for each devian developer obviously there is a lot of stuff that we will never use I don't know sounds we have examples for things we do this way let's take my own page packages.debin.org I guess most of the pages are never seen by anybody that's like 100,000 pages for each binary package we have in the archive and not for each binary package but for each version with all arches on one page at least so the question the thing is if you go for a dynamic solution you obviously get more possibilities and you also don't have to use your CPU cycles for things that nobody ever will look at the disadvantage is in the case of the websites it's more difficult to mirror them or you have to choose which parts you want to know which parts should be static and obviously you also increase the load on the server but if you can handle that it's not a problem but that needs to be investigated and followed previously part of the customization for example adding a login name to links to package.qa they would normally something could probably be done with a JavaScript if you found someone to do JavaScript JavaScript and cookies so you don't really need to have a dynamic you can have a pre-generated sort of and if you don't login you get the generic link if you have JavaScript disabled you get the generic link but if you somewhere have a login page you could do that and you could for example fold stuff and have a dynamic stuff to hide things you could probably do that if you find someone who's good at JavaScript so the suggestion was if you really choose a solution or if you really don't want to have dynamic pages right now like a full blown CVS it would be possible to create something in between with a login page and then give the user of the website a chance to adapt some things with cookies and JavaScript for example that if you are identified to the web server the page a little JavaScript on the page that's linked for you obviously it won't work if you have JavaScript disabled but you will have at least I guess most people these days browser with JavaScript enabled 3M doesn't support JavaScript yeah so you give an advantage only to a specific group of users though probably a great part of them so that would be a solution that still fits into the current infrastructure but gives the user some more way to more thoughts into that not sure I care a bit because I'm not sure if it's already been covered but I mean we did some project and we maintain our own web pages mostly because the format on the current web pages are not for humans and we wanted something that the translators and contributors without developer status where they could add information so we started with the CVS version that we could commit to our CVS and we moved on to a CMS later on I think it's been used now and the CVS story has not been a success story because the access rights are not been properly configured so very few people can actually add the information there and we were hoping to get infrastructure for handling translations and it didn't really work out so we have a complete mess on the website at the moment so you should be very careful going to CMSs and hope that they will solve anything they might just create new problems so the story is that he is from DBNando subproject and they moved to a CMS because they didn't because they didn't like the current infrastructure here especially the import format what to contribute and the possibility and it was too complicated for non-DBN developers to contribute and for the translators and they moved to CMS clone was mentioned that is probably the solution and there have been big problems with it because the access rights didn't work they wanted and the translation stuff didn't work out so this tells us that there can be even more problems if you go for CMS and not not only more possibilities so one should plan this step really careful before actually doing it so that you don't end up with something that's worse than current solution ok so if there is nothing near to this point so one thing I was thinking about was how to make we have already touched it in previous discussions how to make the subprojects more visible and how to better show the whole structure of the living community and what I I was interested in if you have more thoughts about it so my idea was that we try to create a separate page for subprojects and groups and things like that so that we don't hide them in the developers corner like right now and this was just an idea for me and I would be interested if you have thoughts on that are there any things you want to add to this something ok that seems not to be the case so for another thing that was also mentioned very often is for the layout the usability excuse me, I've got a question but who will maintain these pages the web site group or each project yeah ok so there was indeed a question to the point of making a separate page for groups and teams and subprojects so the question is how to maintain this I think the obviously the list of project that are links from there has to be maintained by the web team but I guess each group and each team it's their own decision whether they want to be on the main web site like most of the CDDs are currently or if they want to have their own pages like giving women has so that should be really left to them and we should basically try to give them the possibility to present themselves other thoughts on that would it be possible to import from CVS maintained by a subproject into the main web site so that you would have distributed access rights management for the source like to do the dog for something yeah so the question was would it be possible to still include stuff that is maintained somewhere else like in different CVS or in the different VCS so some people might prefer subversion or darks or arch or something like that but to still include it in the web page like for subproject and that's easily be possible so we do that okay so we do that this already for the all the documentation stuff maintained in the different CVS in the even dog and we still include it in the web page so that's possible the only thing one has to consider is whether to choose different layouts or try to integrate them also in the layout of the main page to consider the translation work the translation framework has to consider it as well so do you want to use the one the devian website or do you want to be integrated with this this isn't the case for devian doc right now so we don't have really experience to include other CVS in the same framework but should be possible or do you want to maintain translations on your own so like devian doc does currently because they have very it's very different to translate the web page translating the whole documentation other thoughts questions ok he basically said that we should do this do the splitting up of some of the crowded pages like developer's corner it's really a good thing to do anyway so we should really do this fast ok let's make a little so it has been about an hour right now so if you want we can make a short the people that want to go to the Apple talk that starting at 11 at the big auditorium can go there and that we can perhaps take a little nap of fresh air and think that that would be needed would you like that or would you go on ok I don't see don't see objections but I see agreements so let's make five minutes ok