[Kde-accessibility] Potential GUADEC/Akademy a11y BOF? (was Re: Planning for GNOME 3.0)

[Brian Cameron]

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 at gnome.org
>>> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>> _______________________________________________
>> desktop-devel-list mailing list
>> desktop-devel-list at gnome.org
>> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
> _______________________________________________
> kde-accessibility mailing list
> kde-accessibility at kde.org
> https://mail.kde.org/mailman/listinfo/kde-accessibility