|
»
Potential GUADEC/Akademy a11y BOF? (was Re: Planning for GNOME 3.0)
|
View:
New views
2 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
Re: Potential GUADEC/Akademy a11y BOF? (was Re: Planning for GNOME 3.0)
by Brian Cameron
::
Rate this Message:
Willie: I would be interested to attend such a BoF. I think that all three topics you mention are important. Perhaps another agenda item to discuss how GNOME 3.0 will impact a11y would also be appropriate. I think the Bonobo/CORBA deprecation falls into this category, but I think there are other issues. How, for example, will clutter-based metacity and gnome-shell work with a11y? Brian > Tomorrow (Friday) is the deadline for GUADEC/Akademy submissions. I'm > curious if there would be interest in setting up a GUADEC BOF around > accessibility? My personal goals would be to focus on three main areas: > > 1) Bonobo/CORBA deprecation, including AT-SPI/D-Bus, magnification, and > speech > > 2) Alignment with KDE a11y > > 3) WebKit a11y > > I think we agree these are all important. But, I'm curious if people > who will be attending GUADEC/Akademy would be willing to attend and > participate in such a BOF and if we can get critical mass to make them > worthwhile. In addition, if the response is overwhelming, should we > consider making separate BOFs? > > Will > > Willie Walker wrote: >> I'm really excited about GNOME 3.0. There are a lot of great ideas that >> people have come up with. >> >> As people work on new GUI designs, I request that people engage the >> GNOME accessibility team on their designs. Accessibility is a big >> selling point for GNOME and I'd really hate to see it take a step back. >> >> Too often, GUI designers and developers forget about important details >> such as keyboard access, theming, and support for the AT-SPI. It's a >> lot easier to develop for accessibility from the beginning than to >> retrofit later. Engaging earlier than later also helps us act more like >> a team than adversaries. >> >> For developers local to the Boston area, I'm happy to take a visit to >> your sight to go over accessibility considerations and to discuss your >> new UI's with you from an accessibility standpoint. I promise to focus >> solely on accessibility considerations and will avoid general armchair >> HCI quarterbacking. For those outside the Boston area, we can try to >> find someone to visit you for a face-to-face and/or we could do >> conference calls with screenshots or just shared desktops via VNC. >> >> Thanks! >> >> Will >> (your friendly GNOME a11y guy) >> >> On Apr 2, 2009, at 7:17 AM, Vincent Untz wrote: >> >>> During the first few months of 2008, a few Release Team members >>> discussed here and there about the state of GNOME. This was nothing >>> official, and it could actually have been considered as some friends >>> talking together about things they deeply care about. There were >>> thoughts that GNOME could stay with the 2.x branch for a very long time >>> given our solid development methods, but that it was not the future that >>> our community wants to see happening. Because of lack of excitement. >>> Because of lack of vision. Slowly, a plan started to emerge. It evolved, >>> changed, was trimmed a bit, made more solid. We started discussing with >>> a few more people, got more feedback. And then, at GUADEC, the Release >>> Team proposed an initial plan to the community that would lead the >>> project to GNOME 3.0. Quite some time passed; actually, too much time >>> passed because too many people were busy with other things. But it's >>> never too late to do the right thing, so let's really be serious about >>> GNOME 3.0 now! >>> >>> Let's first diverge a bit and discuss the general impression that GNOME >>> is lacking a vision. If you look closely at our community, it'd be wrong >>> to say that people are lacking a vision; but the project as a whole does >>> indeed have this issue. What we are missing is people blessing one >>> specific vision and making it official, giving goals to the community so >>> we can all work together in the same direction. In the pre-2.x days, the >>> community accepted as a whole one specific vision, and such an explicit >>> blessing wasn't needed. But during the 2.x cycle, with our six months >>> schedules, it appeared that everything (community, development process, >>> etc.) was just working very well, and as the vision got more and more >>> fulfilled, the long-term plans became less important as we focused on >>> polishing our desktop. But we've now reached a point where our next >>> steps should be moving to another level, and those next steps require >>> important decisions. This is part of what the Release Team should do. >>> Please note that Release Team members don't have to be the ones who have >>> the vision; we "just" have to be the voice of the community. >>> >>> (As a sidenote, the roadmap process [1] that we tried to re-establish >>> two years ago was a first attempt to fix this. Unfortunately, it turned >>> out that we were missing the most important side of things: a >>> project-wide roadmap. This is because a collection of individual >>> roadmaps isn't enough to create a project-wide roadmap.) >>> >>> So let's go to the core topic and discuss what the GNOME 3.0 effort >>> should be. We propose the following list of areas to focus our efforts >>> on: >>> >>> - Revamp our User Experience >>> - Streamlining of the Platform >>> - Promotion of GNOME >>> >>> There are also other potential areas that are worth exploring if there >>> is enough interest from the community. >>> >>> From a release management perspective, there are various questions that >>> are raised in the GNOME 3.0 context. We definitely need a plan to >>> organize the development (see below for details on it), but we might >>> also want to take this opportunity to rethink how we ship GNOME: are the >>> module sets still the best way to deliver GNOME? There is no obvious >>> answer to this, but the way we will present GNOME in the future will >>> certainly have an impact on this. >>> >>> >>> Revamp our User Experience >>> ============================ >>> >>> When talking with some great people at GUADEC about GNOME 3.0, one >>> concern that came more than once was that it would be an error to do >>> GNOME 3.0 without any big user-visible change. While some of us didn't >>> necessarily agree with this concern, it was still a fairly valid one. >>> But it turns out that if you tell the community that there's something >>> after 2.x, then the community will stop vaguely thinking about future >>> ideas and start working on concrete plans. >>> >>> It seems pretty clear now that there are two important ideas that can >>> have a real positive impact on the user experience: >>> >>> - GNOME Shell [2]: the shell idea is not just about changing the panel >>> and the window manager. It's about changing the way you start an >>> activity and how you switch between two different activities. Or more >>> generally, how you manage your different activities on the desktop. >>> >>> - Changing the way we access documents (via a journal, like GNOME >>> Zeitgeist [3]): having to deal with a filesystem in their daily work >>> is not what makes users happy -- on the contrary, they generally just >>> want to access their documents and not to browse their hard disk. >>> Providing new solutions to this problem (using timelines, tags, >>> bookmarks, etc.) is something that has been of interest in our >>> community for a long time, but we never completely jumped in. We >>> simply should. >>> >>> These two ideas can form the basis of an overhauled GNOME user >>> experience; they are not the only changes that we can and will do, but >>> they definitely are the most advanced projects to help us move forward >>> in terms of user experience. The GNOME Shell and the GNOME Zeitgeist >>> projects are indeed already well underway, with working code and strong >>> development going on for nearly six months. This means the effort is not >>> about starting those projects, but about first completing them so that >>> people can work daily with them, and then polishing them. >>> >>> There's one obvious question related to those potential changes: what >>> will happen to the old way of doing things? For example, will we still >>> make the GNOME Panel available if, for some reason, people are not >>> immediately happy with GNOME Shell? There's no obvious answer to this, >>> and this will have to be discussed. Some of us believe that it would be >>> a good thing to keep providing the old elements for a limited time, to >>> ease the migration. That being said, doing that would obviously take >>> some development resources and slow down work on what should be the >>> future. Not an easy choice, of course. However, it's worth noting that >>> distributors and other community members using GNOME to build enterprise >>> products will most certainly help maintain the GNOME 2.x shell for quite >>> some time, and the project will support that to the greatest reasonable >>> extent. >>> >>> >>> Streamlining of the Platform >>> ============================ >>> >>> Since GNOME 2.0 was released in 2002, there have been quite some changes >>> in our developer platform: new APIs have landed and some other APIs have >>> been deprecated. There are even some platform libraries that are now >>> nearly unused. This just creates some confusion and does not make the >>> life of developers easy. Since we want applications to be developed for >>> GNOME, this is an issue that we should fix. >>> >>> Hence, it makes perfect sense to rework our platform and try to clarify >>> it for newcomers. Here are some steps that should be considered: >>> >>> - move all of the deprecated libraries out of the platform, so people >>> stop using them in new code; >>> >>> - create a staging area in the platform for libraries that aim to be in >>> our platform but do not offer enough guarantees at the moment (like >>> GStreamer): this will send a clear message on what should be used; >>> >>> - include new exciting technologies that we're starting to see used in >>> our desktop. Some obvious examples are 3D effects (with Clutter) and >>> geolocalization (with GeoClue and libchamplain). >>> >>> - rework the way we present the platform to also integrate some of the >>> external dependencies: while, say, D-Bus or Avahi are external >>> dependencies, they are definitely what we want developers to use. And >>> it's easy to be more explicit about this. >>> >>> - move the bindings closer to the platform when we talk about bindings, >>> to make them even more visible and attract developers from all >>> languages. >>> >>> The work that has been done on GObject introspection [4] will also >>> deeply change the way GNOME development can be done; we've already >>> started to see how it can be leveraged in GNOME Shell, and the fact that >>> it can bring new popular languages like Javascript to GNOME is a huge >>> benefit. >>> >>> All this has of course an impact on our applications: we will have to >>> port the code away from all deprecated APIs, but also prepare our >>> applications to be ready for forthcoming changes, like GTK+ 3.0. This is >>> luckily a task that we can easily quantify and the progress can be >>> tracked on a simple web page. >>> >>> >>> Promotion of GNOME >>> ================== >>> >>> Our community has historically been strong on the development side, but >>> we have always struggled to promote GNOME. That's because this is >>> certainly no easy task. Our user base has however grown significantly >>> since our project started, and we failed to recruit people that could >>> have helped here. GNOME 3.0 is an opportunity to change this and attract >>> contributors that can help forge the communication around the GNOME >>> project. The promotion of the project is definitely part of what makes a >>> good release, and the Marketing Team can contribute a lot to the success >>> of 3.0. >>> >>> Of course, an obvious goal for the promotion of GNOME in this context >>> would be preparing the 3.0 release and the messaging around this >>> release. After highlighting the changes done specifically for 3.0, one >>> other immediate idea is to simply show the progress the GNOME project >>> has made since GNOME 2.0: GNOME 2.10 could arguably have been named 3.0 >>> when compared to 2.0, and the same goes for 2.20. This could serve as a >>> basis for work on explaining why our evolutionary approach in >>> development works well. >>> >>> One common issue that often came up when discussing how to promote GNOME >>> was that promoting the desktop as a whole is difficult. But there's no >>> need to do that. We can instead focus our messaging around the GNOME >>> experience: the basic GNOME experience simply is the GNOME Shell; but >>> users actually do not use just the basic desktop, and they use >>> applications. We've never explained why the applications developed for >>> GNOME are good; we've never really put those applications under the >>> spotlight. For instance, why shouldn't we put on the front page of the >>> GNOME website a clearly labeled message about a good music manager? We >>> wouldn't have to choose between Rhythmbox or Banshee: we can promote >>> both, since both are good in different ways, and both are good examples >>> of the GNOME experience. >>> >>> This leads us to a third item: relaunch our website. While our current >>> website is known for being broken in various different ways from a >>> communication point of view, we've not been able to deliver the new >>> version that would fix things. Fixing the website is a large task, but >>> we should not give up on this: the GNOME website is a core part of the >>> GNOME identity, and we cannot ignore the current issues. This happened >>> because of lack of manpower, but the good news is that there are web >>> developers that are fond of GNOME and just don't know they can help the >>> project. >>> >>> And the fact that web developers can play an important role is also >>> valid for all of our users. As of now, we are not really empowering >>> users to promote GNOME: what should a user do if he wanted to do so? We >>> all know how some viral communication can benefit a project like ours, >>> so the solution is simple: let's give ourselves a chance to make this >>> happen! >>> >>> >>> Other Potential Areas >>> ===================== >>> >>> The areas presented above are actually not a big surprise to anybody >>> following the GNOME development and are fairly obvious choices. However >>> there are other candidates that would help make GNOME 3.0 a success. >>> Those potential focus areas simply need people to step up so we can be >>> sure expectations can be met. >>> >>> - Desktop Testing [5]: with the recent creation of the Desktop Testing >>> Team, this topic becomes more and more visible. We can innovate >>> there, and we actually should: we helped show the way in the free >>> software world when it comes to usability and accessibility, and >>> there is no reason for us not aiming at a similar experience for >>> desktop testing. >>> >>> - Art: a GTK+ Theming API hackfest was held in February, where some >>> good consensus was reached on how theming should be done in the >>> future. This gives us a new opportunity for an updated look and feel. >>> This can happen with the help from artists: if we have artists and >>> coders working together, with the coders knowing the needs from >>> artists, then there is no doubt that the result will simply rock. >>> >>> - People: the telepathy framework has nicely progressed over the last >>> few years and it's offering great perspectives to integrate instant >>> messaging, and more generally, interaction with people in other >>> applications. With some focus, it could contribute to make GNOME a >>> social desktop where you do not only work on documents, but where you >>> also really interact with your friends. >>> >>> - Mobile: the GNOME Mobile platform was first introduced in GNOME 2.24, >>> and it helped make our presence in the mobile world visible. A lot of >>> the changes that are planned around the platform are of direct >>> interest to the Mobile Team. >>> >>> >>> Organizing the Development >>> ========================== >>> >>> We need to define a clear timeline for the development, with a schedule >>> that will let us check that the development is on the right path. The >>> end goal is simple: we want to deliver GNOME 3.0 by the time of 2.30 >>> release. This makes sense for various reasons: from a technical >>> perspective, the timing is good for the integration of new technologies >>> or projects (GNOME Shell, for example); from a messaging point of view, >>> the evolution from 2.30 to 3.0 is logical and easy to understand. It's >>> worth pointing out that if you compare GNOME 2.26 with GNOME 2.0, it's >>> actually quite surprising to see that we have still kept a 2.x version >>> numbering while we could be at 3.x, or even 4.x. Making GNOME 2.30 a 3.0 >>> version is of course still an ambitious goal, but we can achieve it >>> thanks to what we learnt in the past. >>> >>> The development methods we have adopted during GNOME 2.x are overall >>> good methods and the community has become used to them. For example, >>> contributors understand the reasons behind the freezes we have and try >>> their best to respect those freezes. This is not something that should >>> be changed because we now have an opportunity to try something else; on >>> the contrary, those methods will make our path to 3.0 easier. Some >>> regressions were pointed out during the past few cycles: those should >>> not be ignored and we believe part of the reasons why they happened is >>> that only a subpart of our community was trying to move forward, which >>> created some controversy; having a community-wide focus should limit >>> those controversies, and hence the regressions as felt by the community. >>> >>> The six months cycle is now part of our culture and has an impact on the >>> free software ecosystem, with distributions basing their schedule on our >>> schedule. Trying to change this crucial element of our release >>> management, which works quite well, would certainly not help us in any >>> way. Therefore, we will keep six months-based schedules. But having >>> project-wide and long-term goals require some adaptation. GNOME 2.28 >>> will not be an independent release or a destination in itself, but it >>> will be a logical step towards GNOME 2.30, and therefore GNOME 3.0. >>> >>> Of course, we should be prepared to consider the fact that GNOME 2.30 >>> might not be good enough for us to call it 3.0. All of our time-based >>> releases are also quality-based releases: if the QA Team feels a release >>> should be delayed, then it will be delayed. In the context of 3.0, this >>> is something that we should be ready to diagnose early on during the >>> 2.29 development cycle and we should not be afraid of keeping GNOME 2.30 >>> as 2.30 and waiting for GNOME 2.32 for the 3.0 release, for example. >>> That being said, we want the community to try as hard as possible to >>> make "GNOME 2.30 = GNOME 3.0" a success. >>> >>> On a more general note, overlaying a long-term development cycle (3 >>> years for example) with project-wide goals, on top of our six months >>> development schedules is something we want to keep after GNOME 3.0. >>> >>> >>> Conclusion >>> ========== >>> >>> You can already check out the schedule for the 2.27 and 2.29 development >>> cycles [6]: it contains some concrete steps and deadlines that will help >>> keep our work focused to make GNOME 3.0 a reality. >>> >>> As already mentioned, this is an ambitious plan and it will only be >>> realized if everybody comes out and helps. Companies can contribute a >>> lot -- for instance, the GNOME Shell effort is doing great thanks to Red >>> Hat's involvement. But GNOME wouldn't even exist without all of the >>> volunteers who are passionate about the project. It's because this >>> passion is so strong that we can build such a plan! >>> >>> We're getting there. We strongly believe that all this can make a good >>> plan for GNOME. Sure, it's not perfect. And there will be disagreements >>> and issues along the road. But it is the way forward. >>> >>> >>> The GNOME Release Team, >>> >>> >>> [1] http://live.gnome.org/RoadMap/Process >>> [2] http://live.gnome.org/GnomeShell >>> [3] http://live.gnome.org/GnomeZeitgeist >>> [4] http://live.gnome.org/GObjectIntrospection >>> [5] http://live.gnome.org/DesktopTesting >>> [6] http://live.gnome.org/TwoPointTwentyseven >>> >>> -- >>> Les gens heureux ne sont pas pressés. >>> _______________________________________________ >>> desktop-devel-list mailing list >>> desktop-devel-list@... >>> http://mail.gnome.org/mailman/listinfo/desktop-devel-list >> _______________________________________________ >> desktop-devel-list mailing list >> desktop-devel-list@... >> http://mail.gnome.org/mailman/listinfo/desktop-devel-list > > _______________________________________________ > kde-accessibility mailing list > kde-accessibility@... > https://mail.kde.org/mailman/listinfo/kde-accessibility _______________________________________________ kde-accessibility mailing list kde-accessibility@... https://mail.kde.org/mailman/listinfo/kde-accessibility |
| Free embeddable forum powered by Nabble | Forum Help |
