Corebird — my first package as a package maintainer — has just been built and submitted to Bodhi. If you have a chance, test it, and leave some karma!
You may be aware that in the past year my husband and I had a baby. Yet, I’m still here and participating in the community. That’s no small feat and is due in part to the help and support of my family, my managers and my employer (Red Hat,) and many of my peers who are also moms in tech.
My friend Kathryn Rotondo recently put together a proposal for a new podcast – the Motherboard Podcast – to provide ideas and advice for other women in technology, like me, who would like to start a family but are worried about how it might affect their career, or who are already trying to balance both and are feeling alone. She will interview women with children who are working at tech companies; they will discuss the challenges they ran into, solutions their families came up with, and other issues. I think we need more role models for women in technology in general, but especially role models who are able to raise a family while continuing their career, so the interviewees for this podcast will be a great start.
The podcast will be available for free and will tentatively be licensed under a Creative Commons license.
Kathryn also put together a great video introducing the podcast project and making the case for it, so please have a look.
Anyhow, please support the Motherboard kickstarter if you can, and help tech moms like me feel connected and supported!
Das LibreGraphicsMeeting 2014, die dann 9te Ausgabe wird vom 2. – 5. April 2014 in Leipzig an der dortigen Universität statt finden. Das LibreGraphicsMeeting versteht sich als Arbeitstreffen nahezu aller offenen Grafikprojekte, also alles was mit Typographie, Vektorgrafik, Animation, Bildbearbeitung und Fotografie zu tun hat. Auch Nutzer dieser Programme wie GIMP, Inkscape, Scribus, Krita, Mypaint sind aufgerufen zu partizipieren, denn nur durch den Austausch mit den Nutzern kann eine Weiterentwicklung der Programme erfolgen. Die Teilnahme am LGM ist wie immer frei, um die anreisenden Entwickler und Enthusiasten zu unterstützen gibt es auch in diesem Jahr eine Pledgie-Kampagne. Wer sich für den Call for Participation interessiert findet diesen hier, bis zum 15. Januar können noch Beiträge eingereicht werden.
Some days ago I was on OpenRheinRuhr, an event in which I participate since the begin. Last year there was unfortunately no OpenRheinRuhr as the place was taken by another exhibition. I manned together with Felix and Christian the Fedora booth and besides of that I had a talk and a workshop in the schedule.
My talk was about the status of open source animation programs, where in this year a lot of things happend. Hopefully the upwind that area has right now, tails not off to soon and will show effect. The workshop I had was this time not about Inkscape like always, it was about Blender, the time was really short so the workshop became more an demonstration. What actually turned out really nice. Both talk was workhop was well visited and a lot of questions and interesting conversations came up after them. Think I will do OpenRheinRuhr next year again.
I’d like to let you know about a little initiative the Fedora Design team is starting related to the Fedora.next effort.
Hopefully by now, you’re aware of the Fedora.next initiative. Among other things, Fedora.next involves splitting Fedora into three separate products:
What each of these ‘products’ will be, exactly, who they are targeting, and their various features, etc. is up to working groups that have been formed for each product. Information about the working groups is available at their respective wiki pages (linked to above.) Those working groups will come up with product requirements by January 2014, at which point we’ll have more information about each product and what it will be like.
Having more than one main ‘product’ for Fedora is going to result in our team – the main caretakers of the Fedora brand – having a lot of requests we aren’t quite equipped to handle right now. Here’s a few example questions, some of which we’ve gotten, to show what I mean:
How do we answer these kinds of questions? How do we get on the same page about how to answer these questions? Over time as these Fedora product plans solidify, we’ll need to come up with a ‘brand framework’ to support them all. (This sounds very fancy but it really isn’t. I think it’s just going to amount to some extensions to our current brand guidelines.)
While I don’t think there’s much reason to stray from the above knowing our brand, we may tweak here and there based on our research on the different products. Also, of course, the particulars of how we extend the brand framework will require that research before we can even get started.
How do we develop these extensions onto the Fedora brand and build out our branding framework to be able to encompass multiple products?
Are you interested in getting involved with this effort? Here’s the right places to continue the conversation or start a new one (or feel free to post in the comments on this blog post instead of course!):
Corebird is an awesome GTK+3 desktop twitter client. I am in the process of getting it added to the official fedora repos, but in the mean time, i have a version packaged — for fedora 20 only — and ready to be used in my fedorapeople repos.
To set this up on your Fedora machine, first download the .repo file:
sudo curl -o /etc/yum.repos.d/fedora-corebird.repo http://repos.fedorapeople.org/repos/ryanlerch/corebird/fedora-corebird.repo
Then install corebird:
To set this up on your Fedora machine, first download the .repo file:
sudo curl -o /etc/yum.repos.d/fedora-polari.repo http://repos.fedorapeople.org/repos/ryanlerch/polari/fedora-polari.repo
Then install polari:
sudo yum install polari
Today was the second meeting of the Fedora Server Working Group!
Here are the various resources currently affiliated with the Server Working Group that you can use to follow along or participate:
Here’s a run-down of today’s Server Working Group meeting:
Today’s meeting actually took two hours. We devoted one hour to each of the topics below.
We had a discussion about two pending issues with the governance charter before ultimately approving it. The two issues were:
We had a long thread on the mailing list about the group membership concerns brought up at the first meeting. While we reached some agreement in the thread (we will not require any form of experience / proof that a member has experience with server technology to become a voting member of the server working group,) we weren’t able to come to consensus on whether or not voting seats on the working group should be earmarked for members of specific Fedora groups.
So we talked about that last dangling issue first during today’s meeting. I brought it up in this way, “There seemed to be a lot of concern about having chairs represent specific sigs/ other teams in fedora last meeting, I didn’t see that resolved on list.”
mitr replied, “Seems to me that way as well. I’d still prefer not having reserved seats; we can set up liasons when/as much as necessary.”
nirik agreed: “…involvement from many parts of the project is vital, but not sure that each group needs a voting seat…”
Viking-Ice expressed concern that if the seats are just liasions with the other groups and not members of the other groups, that the work we need those other groups to do won’t necessarily get done. Conversely, nirik was concerned that, “groups may not want the time/involvement that a voting seat would be… they just want to know/help where it affects their main focus.”
We came to agreement after this discussion that it made sense to drop the group mappings for now, but to also be sure that we added a note to the membership section that we encourage involvement from all parts of Fedora.
nirik brought up the concern, “Currently we have it so turnover only happens if someone steps down from a voting seat. Do we want any term limits or other ways to keep a flow of fresh blood into the voting group?”
The discussion below is out-of-order, but grouped according to the threads of conversation, which were running concurrently for the most part.
Viking-Ice felt the Server Working group would dissolve once the PRD and process were put in place. He suggested indefinite terms and no elections, with the thought that the group would be short-lived. nirik believed that the group’s lifetime might be quite a bit longer, in saying “I think there will be ongoing work for this group for a long time…”
mitr added, “I’d almost say that the actual work _starts_ after the PRD, although the nature of it will change (coordination, prioritization of the “next service”, choosing software used to implement the PRD).”
“[W]hich product [gets chosen] or dropped is left up for the entire server community to decide (with the exception of the first three or so maybe to get the process nailed down,)” responded Viking-Ice.
mitr replied, “I don’t think people just following PRD can work. E.g. choosing between puppet/ansible/$many_other_alternatives needs to and up with a definite decision.”
“We are that decision making body?” nirik asked Viking-Ice.
“For the first products,” replied Viking-Ice. “[N]ot all products.”
nirik then said, “Well, for the products we decide that the Fedora Server group is going to ship, sure.”
A conversation came up as to how we would hold a vote for new members if we were going to have terms.
“It is also not easy to organize an election,” pointed out tuanta. I pointed out that depending on the scope of the election (e.g., not the whole Fedora community but maybe just the server community, using the Fedora elections app or more informal in IRC or over the mailing list), it could be easier to organize.
mitr added, “I’m not tied to the Fedora election app, but (from the outside) it seems that it’s easier to use that app than to manually count votes, and the confidentiality is a significant benefit.”
nirik stated a preference to avoid the elections app.
Evolution suggested a 6-month seat vote, but mitr wasn’t sure a 6-month term would work with an 18-month lifecycle.
mitr pointed out, “I’ll reiterate that I don’t think having indefinite terms is healthy, although this seems to be a minority opinion among the WGs.” However, both myself (mizmo) and nirik stepped up and agreed with him.
As mentioned earlier, Viking-Ice was in support of not having term lengths and instead having indefinite terms. “I personally dont see the need for the WG once the process is set,” as he stated his perspective on this. “No election[.] It would be better to simply have members confirm the continue[d] participation in the server WG every 3 or 6 months.”
I asked the group what specific concerns they had about Viking-Ice’s indefinite terms proposal. mitr responded, “The WG confirming itself is not an effective mechanism for replacing a dysfunctional WG. (I know we are all perfect and this is purely theoretical )”
After asking Viking-Ice if he had some way to account for that scenario, he replied, “Use the same approach as you propose we cross that bridge when we get there.” He also suggested that FESCo could be brought in to resolve issues in the case of dysfunction; when asked nirik said FESCo might be open to serving in that capacity.
I brought up my own specific concern about Viking-Ice’s proposal. “I’m worried about stagnation – usually the energy of new members coming on board regularly helps jump start people’s enthusiasm at the regular intervals of election. it doesn’t seem like this would be guaranteed in your proposal,” I said. “Do you have ideas on how to account for this in your proposal?”
“[L]ook at fesco same people for the last deca[d]e more or less,” he replied. “Fresh ideas killed instantly by the few fresh members that make it there so..”
In response, nirik then proposed another idea to help bring fresh members to the team, “Every 6 months we randomly choose 3 members to replace (would also need at least 3 more active folks in the group to replace them with.)”
This didn’t really go anywhere though, and nirik noted we had 10 days to submit a governance charter to FESCo.
nirik continued, “I’m not coming up with too many great ideas there… and it might depend on: a) how long we exist, b) how many non voting active people their are in 6 months, c) if we need more fresh voting members or if as Viking-Ice notes the active people in the community would be enough for that.”
“Actually… _if_ we are agreed that we should have some kind of turnover mechanism, then delaying might make sense; if we don’t have an enforced turnover, then let’s just close it now,” said mitr.
I responded, “I do think we need a turnover mechanism, but I agree with nirik that it’s kind of hard to know how to set that up without seeing how active the community membership is and how long we intend to exist.”
At this point, nirik proposed we vote on going with Viking-Ice’s proposal of indefinite terms and periodic (every 6 months) confirmation of working group membership. To interject some personal opinion here, it felt like consensus by exhaustion to me, and at least three people remarked while voting they were voting the way they were to ‘get this over with.’
At the very end of the discussion mitr brought up the fact that the statement about quorum in the charter wasn’t technically correct with respect to the definition of quorum. It said we must have a quorum of 5 people to vote, which means the majority of 5 people (which is 3) positive votes would be required to agree to something in a vote. The intention behind the statement was to require 5 positive votes, regardless of how many people were present at the meeting, so the verbiage was updated to reflect that and all agreed to it.
So as of this meeting then, the Server working group has approved its governance charter as updated with the agreements and language discussed above:
Stephen Gallagher, our FESCo liaison, will bring the charter to FESCo for approval.
We’d taken up an hour by the point we finalized the governance charter, but I think everybody present was able to continue on and the #fedora-meeting-1 room was empty still, so we went on for another hour.
The topic, “Is Fedora Server One Product?,” came from a thread of the same name on the server mailing list. The thread is relatively short:
That was where the mailing list left off. The discussion in the meeting, though, was unfortunately a lot less efficient than the mailing list thread. I think we basically talked at each other saying the same exact thing using different terminology and getting confused over language. At one point I declared ‘product’ to be a dirty word and tried to come up with a different word to get around the blockage we kept running into. I will try to outline the path of the discussion so you can draw your own conclusions.
I started off by answering the question, “Yes, I think it’s one product.” When Viking-Ice asked me why, I had my ux-design and fedora-websites hats on, thinking about how 500+ ‘products’ would be represented on our web page. I made the point that, “If Fedora as a whole is to have three products [workstation, server, cloud], we’re kind of bursting at the limit of what potential end-users are going to be able to handle.”
nirik pointed out that we may be each thinking of something different for the meaning of the word “product.” He tried to ground the notion with a specific technical example: “Taking it from the deliverables angle, it sounded like people might like kickstarts + a netinstall iso… so we could produce N kickstarts for use with a netinstall… is each of those a ‘product’ ?”
“nirik, i wouldn’t consider those a product no,” I responded. “They are different configurations for the same product.”
Viking-Ice responded to nirik, “If it has gone through the transitioning process ( which I say is prd ) then yes.”
“So, it sure sounds like a terminology thing to me. ” concluded nirik.
“I think: just different meanings of what a product is,” tuanta added.
Unfortunately, the confusion didn’t end there.
sgallagh proposed, “To my mind, the Fedora Server as a product is a well-defined set of solutions that we have vetted for people to use. These solutions can be divided into ‘roles.’”
mitr said, “I think the common infrastructure (kernel, booting, basic libraries, choice of configuration/management/…) framework needs to be uniform for all deployments. There may be specific separate “single-click” ways to install a specific role (corporate LDAP / mail / Java application server, whatever), but those are all “roles” of a single product to me.”
In response to mitr, Viking-Ice stated, “I would call that common infrastructure between prd’s but I even doubt that it would be applicable to all of them.”
mitr responded, “When I said “needs” to be the same, I did mean “needs” – we will be manpower-constrained even for the new things that we need to do, reinventing the same functionality for different kinds of servers is a waste we can’t afford.” He continued, “I agree it’ll kind of strange if we announce Fedora Server 1.0 !!! Implements all of …. 2 TCP protocols! but the overall direction should be of a single product with multiple roles.”
“I mean, absolutely, each role needs to be defined,” I also responded to Viking-Ice, “but I think a PRD for each role is overkill.”
“Only one the base OS can be labeled a product,” said Viking-Ice.
nirik said that he “largely doesn’t care. call them ‘roles’ or ‘products’ does it matter in the end?”
“From my perspective,” sgallagh offered, “the duty of the Product would be to set the definition of how something gets promoted into a ‘supported’ role in that Product.”
mitr pointed out to Viking-Ice, “Or perhaps to take it from a different view, even if we have a nice pre-packaged LDAP and mail solution, I should be able to install a _single_ physical server that serves both, shouldn’t I?” If the pre-packaged LDAP solution was one ‘product,’ and the pre-packaged mail solution was another ‘product,’ the question here I think is whether or not you could combine two ‘products’ on one physical server.
mitr continued, “installation is an implementation detail at this level of discussion I’d say. I kind of like having a ‘single big installation medium,’ but a minimal netiso that allows installing the various roles would work just as well.”
“We need to be able to handle this on per product [basis] as in ldap as one product and a mail server as another,” Viking-Ice responded.
“Why?” asked mitr.
“[The] workstation working group has multiple and I suspect it’s going to blow over due to [its] gnome-ism and the DE community’s [way] with it,” Viking-Ice responded. “The cloud depends on our mutual definition of what is cloud and what is server and the [environment] and baseos [don't] have 1 multiple apps so to speak. I see products as single or multiple server application which an roles could be applied upon.”
I asked, “What are other working groups calling what they are working on? Do they have roles vs. products issues?”
mitr responded, “I think the other groups don’t have the equivalent of an ’1-click mail server’ use case.”
“There are some different desktops (Gnome, KDE, XFCE, etc.) in Workstation WG,” tuanta pointed out. “It is also equivalent, I think.”
At this point I tried to do a recap of the multiple concurrent threads:
After a lot of the above discussion, which occured in a more interleaved manner than represented above, sgallagh tried to call some order: “Can I take a step back here and try to center us on the question we’re trying to answer? Could we agree to work on separate chapters of the same PRD for now, with the option to split them up later if it becomes obviously necessary?”
nirik pointed out that he “thinks prd per application is overkill, but perhaps thats me.”
“Trying to apply a prd to the entire group is [nonsense,]” responded Viking-Ice.
I offered, “Let me tell you why I think PRD per application is overkill, and you let me know what you think – the PRD for each of those applications is the responsibility of upstream, not us. The upstream FreeIPA team, for example, is responsible for the FreeIPA PRD. We are only responsible for the PRD of the platform on which applications and stacks like that are meant to be deployed on.”
sgallagh said, “I don’t agree with that 100%. I think we should be able to modify those packages to fit with our goals.”
“I disagree with that,” said mitr, “modification and integration of upstreams should be in our scope as well.”
“Modification and integration is fine,” I repsonded, “but a full PRD for the application I think is out-of-scope.”
“I agree we will need a PRD for the individual app stacks, to make sure it’s integrated correctly and the like,” said mitr, “but they are all unified by the shared base, config management, monitoring and the like, and _that’s_ one basis of the server PRD; the other being a list of app stacks we want/need.”
nirik added, “I would want a fair bit of information for a ‘role’ or whatever we want to call them… before commiting to producing, testing and delivering it.”
nirik then made a proposal: “Make a single server PRD that includes what information we need from ‘roles’ and includes the initial set of them we intend to deliver.”
“-1 that’s not what prd’s are for,” responded Viking-Ice.
“Ok, then what are they for?” asked nirik.
Viking-Ice replied, “Defining the transition process from an marketing idea to a product.”
nirik said that he was, “confused, really the PRD is for fesco to tell them what we are making right?”
“The server community is not a product,” said Viking-Ice. “Fedora Server is not a product. ‘Fedora Freeipa Server’ is a product.”
“Ok, well, I guess I don’t care if we make a bunch of PRD’s instead of one,” replied nirik, “but I suspect a lot of it would overlap, no?”
Viking-Ice replied, “Yes, hence I said we needed to do 3 or more products so we could identify where they would overlap.”
“Fedora Server is a product in the same way that Microsoft Windows Server 2012 is a product,” sgallagh pointed out.
“I’m pretty sure the point of the PRD is to define the problems a product solves, and in this specific case to let FESCo know what specific problems we feel need to be solved in the server space,” I suggested.
sgallagh said, “I suspect that we maybe just chose the wrong term by calling this document a ‘PRD,’”
“How about ‘Fedora Server Feature Requirements List,’” I offered. “What would we call ‘Fedora Server’ if we were avoiding the word ‘product’?” I came up with “Fedora Server Platform.”
Continuing, I asked Viking-Ice, “Viking-Ice, are you okay with putting together a single functional requirements document for the Fedora Server Platform? That document can include all of the application stacks and roles of interest.”
“Single functional requirements document for the Fedora Server Platform is one thing but dont think we can apply the application stack or roles of interest to it ( yet ),” he replied.
nirik said, “I don’t care what we end up calling things. I want a common base thing (netinstall iso, whatever) and some ‘featured application stacks’ or whatever that we commit to putting together from our collection and making shine.”
“Nirik, i think we all agree, vocabulary hangups aside,” I responded.
Nirik proposed, “common base platform with ‘featured application stacks’ built on top of it. We commit to produce, test and distribute these application stacks,” to which he received multiple affirmative responses. He continued, “Thinking about it, we will need a way to promote/add new applications, so perhaps the requirements doc could just explain how that happens and the applications could be seperate. Whatever works tho.”
I think we kind of fell apart from there, though, and ran out of time. So I’m guessing next meeting we’ll try to pick this topic back up and come to some resolution.
Here is the official meetbot meeting minutes with links to the full raw log:
Today was the first meeting of the Fedora Server Working Group!
In case you’re not aware, let me provide a bit of background on the group first, and then we’ll go through a summary of how the meeting went.
Stephen Gallagher wrote an excellent background to the working group in his announcement of the group’s formation, so this will be a very brief summary. For more in-depth information please refer to his post.
Matthew Miller and Stephen Gallagher (with a lot of input and help of the Fedora community) put together the Fedora.next proposal which he presented at Flock and on various mailing lists; it’s been discussed within the Fedora community for the past couple of months at least. Part of the proposal involves the creation of working groups, three of which are product working groups – Workstation, Cloud, and Server.
The deliverables the working groups are meant to focus on first are the following:
Stephen Gallagher is the Server Working Group’s FESCo coordinator, and he chose a set of self-nominated Fedora community members to serve alongside himself as the nine voting members of the Server Working Group:
Note that anyone is welcome to participate as a non-voting member!
Here are the various resources currently affiliated with the Server Working Group that you can use to follow along or participate:
Here’s a run-down of today’s Server Working Group meeting:
First we talked about how frequently we should meet and at what time. This diverged a bit into other topics (how to handle absences and time zone issues.) We agreed on the following points:
We then moved on to talk about the tools we will use to conduct business – managing and tracking our progress. Some of the asset types that came up as needing to be managed with tools were:
While Stephen suggested initially that we set up a Trac instance to keep track of agenda items and discussions, several members (Jóhann, David, Simo) had concerns about prematurely setting up Trac before we had determined through experience that we needed it. We collectively decided to table any Trac set up and to use the Fedora wiki to trac agenda items, decisions, and discussions until it became too unwieldy. At that point, we would have the experience to fully understand the requirements of the tool we needed and be able to select a tool based on requirements. Again, the overarching concern here, I believe, was simplicity.
I volunteered to start a blog for the group to share meeting minutes and any progress we’ve made (so here you are. ) Initially I’m going to make the blog posts here on my personal blog, but I will also set up a group blog for the Server working group on OpenShift and have that subscribed to Planet Fedora. Meeting minutes will also be posted to the server mailing list as well as to the Fedora meeting minutes list.
It was very unanimously agreed that the working documents would be stored on the Fedora project wiki, following the lead of the Cloud working group.
We then moved on to start discussing the governance charter. Jóhann very helpfully put together a Fedora Server working group governance charter draft which we read through and used to direct the discussion.
Jóhann’s draft has four main sections:
While there was a lot of agreement about the content of the other three sections, there were some concerns and disagreement about the content of the membership section – enough that the discussion was not conclusive and we decided that we should discuss it further on the mailing list and it should be part of the agenda for next week’s meeting.
The main point of contention about the membership section was that there are certain slots in Jóhann’s proposal meant to be dedicated to specific teams within Fedora. There were several concerns voiced about this team-based slot approach:
Hopefully we’ll have some discussion about these points and others and clear up what we think the membership section needs to say.
We only had about 5 minutes left (and went over by 5 more) after determining the main meat of the governance proposal that we had to work on was the membership section. We threw out different ideas for loose threads of discussion and other issues we thought should be considered for the next meeting’s agenda:
Here is the official meetbot meeting minutes with links to the full raw log:
Games often don’t seem like the most important thing for GNOME. Yet, many people expect to have some common games available, and for some individuals being able to play Solitaire or Sudoku is a major reason for having a computer in the first place.
Historically, the GNOME project has developed a fairly extensive collection of games. These used to share some of the same code, but have recently been split up into independent modules and repositories. This was a great move, and I definitely think that each of the games should be allowed to develop into independent projects in their own right. I’m sure there are plenty of opportunities here for new contributors.
I recently spent a bit of time looking at some of our games to try to help raise the quality level. Since there are quite a few games in GNOME, and this was a fairly quick design pass, I decided to focus on the most commonly recognised games that users might expect to be able to use on GNOME. As a result, I’ve so far restricted my work to Sudoku, Tetris (or Quadrapassel in GNOME language), Reversi (aka Iagno) and Minesweeper (aka Mines). I also took a look at Tetravex, since it seems like it could be an accessible puzzle game.
It should be said that I am no graphic designer. These mockups are just the first step, and if you have a flair for graphics and would like to help, your assistance would be most welcome.
The GNOME games developers have been a pleasure to work with, and some parts of the designs have already been implemented. Many of the proposed changes have also been filed as bug reports, so it’s easy to get started if you want to help to make the games into a really fun and pretty.
WOW! Acabo de recibir un regalo tardío de cumpleaños!
En Mayo tuve la oportunidad de asistir al LGM (Libre Graphics Meeting) en Madrid, y reunirme con amigos de la comunidad de Arte libre.
Uno de los amigos me pidió que lo acompañara una tarde a una caminata fotográfica, y con mucha paciencia (además de felicidad porque me prestó su 60D) hice de asistente deteniendo el tráfico, traduciendo al español todo (ya que no habla español), pidiendole a la gente que posara… en fin, una experiencia divertida.
Normalmente estoy del lado del visor de la cámara y nunca poso para nadie más que para mis propios auto-retratos, y en medio del apuro por tomar las fotos a tiempo, un par de veces posé más que por obligación, por broma. Que buena sorpresa me llevé cuando ví que dentro del libro estaba su servidora, como siempre, haciendo caras graciosas.
GNOME’s initial setup assistant was originally introduced in 3.8. It helps people set up GNOME 3 when they first log into a new session, and guides them through the essential steps to make their account usable. It enables you to set a language and the date and time, and it helps you to connect to a network and to online accounts.
Without something like initial setup, there’s a risk that a new user might be faced with a system that isn’t using their language or has the wrong time. Hunting through settings on a misconfigured system is not what we want people’s’ first experience of GNOME 3 to be.
From a design and development standpoint, one of the tricky things about initial setup is that it doesn’t get a huge amount of attention. Those of us who work on GNOME don’t see it on regular basis and our users only encounter it once (or very infrequently). People usually aren’t in a position to file bugs when they’re using it. This makes it difficult to know how initial setup is performing.
I have recently been working with Intel’s OTC London office to investigate this situation further. The OTC recently commissioned a series of user tests in this area, which have provided some excellent data on the kind of experience that initial setup is providing. I’ve been given access to the data generated by these tests, which I have been able to use to improve the design. I’d like to say a big thank you to Intel for funding this work and for being so supportive.
The user tests were run in a fairly conventional manner: participants were given a laptop and were instructed to treat it as if it were their own. They were then invited to run through initial setup. Along the way, a researcher asked them questions about what they were doing, as well as about their understanding of what was happening.
A total of 12 participants ran through the test. One really nice thing about the study was the variety of the participants involved. Of the 12, four had Mac OS X as their primary experience, four had Windows 8, and four used another version of Windows (either XP, Vista or 7). The participants also displayed a range of approaches to the computer – there were careful users who read everything and were very considered, and there were more impatient people who clicked through without much thought. Some were confident, others less so.
The tests were recorded, using a combination of screen recording and a web cam. Unfortunately, technical issues mean that it isn’t possible for the videos to be made available. However, I’ve been given access to the data and have made fairly detailed notes.
As is usually the case with this type of test, the results were mixed. All but one of the participants were able to complete initial setup without assistance from the researcher. Some parts of initial setup worked well, like language and network selection. Reactions to the experience were generally positive.
At the same time, some parts of the initial setup assistant could definitely have performed better. Some of the participants had problems at certain steps, and the purpose of some aspects of the initial setup assistant were frequently unclear.
The main issues encountered by the test participants included:
In addition to these more specific results, there were some other interesting lessons that can be drawn from the study. I think the most significant lesson for me is that the participants really, really disliked passwords.
“[Passwords are] the bit that I always hate, because they always make it complex and I never remember.”
The participants reported having trouble remembering their passwords, and they resented having to create strong ones because it makes them harder to recall. This aspect of the test was by far the most problematic and the one that provoked the most negative responses.
On the basis of the user tests I have been working on an updated set of initial setup designs. These are an evolution of the existing designs.
Two of the panels that the participants didn’t fully understand have been rebranded to clarify their role: “Location” has become “Time Zone”, and “Input Sources” has become “Typing”. The Online Accounts step has also been elaborated to make it much clearer.
Much of the work that was done in the 3.10 cycle to improve adding user accounts in the control center has been carried over; this should hopefully improve what turned out to be the most difficult part of the whole initial experience.
These designs address the worst issues that arose during the user tests, and I’m hoping that we can get initial setup into much better shape for GNOME 3.12. The Intel user tests are an invaluable contribution here, and have provided many other insights that we can follow through on.
Are you or do you know of a woman who is interested in getting involved in open source and would be available for a full-time internship running from Dec 10, 2013 to March 10, 2014?
It’s time to apply for Round 7 of the Free & Open Source Software Outreach Program for Women! As in recent previous rounds, Fedora is going to be participating in this program. We have a number of potential internship projects available. The latest list is always posted on the Fedora OPW wiki page, but here’s a little sampling of the kinds of projects you could get involved with:
You may have been following along with some of my Hyperkitty designs here on this blog – this is a great opportunity to work on it yourself!
Oh! Did I forget to mention, there is a $5,000 stipend for the 3 months of work you’ll be putting in?
Learn more about this program and apply at the Outreach Program for Women site!
I just closed a while ago the election for the election of the wallpapers for the extra package for Fedora 20. And now we have an result, that are the wallpapers that become packaged. For all that are interested in the complete ranking you can find it here.
Recientemente, Richzendy y yo compramos un PS3 y para ser honesta, creo que ha sido la mejor consola que hemos comprado. La calidad de los juegos es genial y la velocidad, ni que decir.
Somos un par de adictos a las Series y Películas y usualmente las vemos en nuestras Pc; sin embargo, curioseando y luego de revisar otros Media Servers, nos gustó bastante el PS3MediaServer. Lo bueno de este sobre los otros es que permite más tipos de archivos de reproducción (utiliza mplayer como base) y permite ver subtitulos.
Es super fácil de instalar, acá, una guía lo más simple posible para que les funcione en menos de 5min :)
Primero, descarguen la versión más nueva de PS3MediaServer desde la página oficial del proyecto: https://code.google.com/p/ps3mediaserver
Luego de descargarlo es hora de instalar algunas dependencias: (Revisen bien que versión de openjdk tienen e instalen esa, varía el nombre)
yum -y install mencoder ffmpeg mplayer vlc java-1.7.0-openjdk
Es momento de tumbar el firewall:
service firewalld stop
Enciendan su PS3. Ahora, como root aún, es hora de navegar hasta el archivo que descargamos (recuerden descomprimirlo) y levantamos el PS3MediaServer.
Esto les levantará la aplicación. Probablemente de error, si sucede, deben ir a la pestaña de “General Configuration” y hacer click en “Force Networking on Interface”. A veces funciona con wlan:0 y a veces con la ip que su sistema les ofrezca, prueben ambas.
Reinicien la app y listo :)
Luego de que el servidor les indique que ha encontrado el PS3 solo deben navegar en su consola hasta la sección de “Videos” y ahí verán el enlace a la app. Con esto podrán navegar en los archivos de su computador y disfrutar de su Media Server.
GNOME 3.10 was released last week. A lot of hard work went into it (I know I felt pretty exhausted by the end), but I think that it was worth it. We ended up with an excellent release.
I’ve been using bits and pieces of 3.10 for some time, and completely adopted it (through Fedora 20) about a week ago. It feels like some important aspects of the GNOME 3 experience have started to fall into place with the latest release. Most obviously, we have quite a few new applications, which fill gaps in the core application set. We are also seeing the application design patterns starting to mature. The addition of header bars makes a fantastic difference.
This release also includes some new things which have been planned for a long time, and which round out features that we released in previous versions. Lock screen customisation is one of these, as is the updated application launching view, both of which feel great.
Another exciting thing that happened for 3.10 is that our efforts to modernise the toolkit have started to bear fruit. GTK+ 3.10 has a whole collection of new widgets which will enable developers to make better applications, and should also reduce the amount of work that they have to do. I really hope that this trend continues with even more new widgets and improvements to the developer experience.
GNOME 3 is already in good shape, but as each release comes by, so the vision as a whole takes another step towards realisation. When that finally happens, I think we’ll achieve a qualitative shift in the kind of experience that we’re able to offer. 3.10 is a strong indication that GNOME is making good progress towards that goal, and is a taste of what is to come. Exciting times.
I recently used fedup to upgrade my Fedora 19 machine to Fedora 20. However, after upgrading to Fedora 20 (which includes GNOME 3.10), i noticed that my normal keyboard shortcut (CTRL + ALT + L) was not locking the screen like it has previously.
After bashing the alt, control and L keys on my keyboard for a few moment, i figured out that in GNOME 3.10, the default shortcut to lock the screen is now changed to SUPER + L.
Note, however, that it is trivial to change this back (or to whatever other key combination you want)using the Keyboard preferences in the GNOME Settings.
Am Wochenende von 19. und 20. Oktober werde ich in Hamburg sein und zwar im Attraktor für einen Inkscape-Workshop. Der fällt etwas kürzer aus von den Zeiten, als sonst üblich, am Samstag von 11.00-18.00 Uhr und am Sonntag von 10.00-16.00 Uhr. Wie immer gibt es eine kleine Anmeldung, nur um zu wissen wer so kommt.
Der Workshop beginnt mit einigen Dingen rund um SVG, der Oberfläche von Inkscape, den Verzeichnissen, Zooming und Panning und setzt sich dann fort mit den Zeichenwerkzeugen. Nach meinen Erfahrungen schaffen wir in bestimmte Themen, wie Live Pfadeffekte, Gekachelte Klone und vor allem Filter nur Einblicke aber die reichen aus, um im Selbststudium sich damit beschäftigen zu können. Wann immer es geht schieben wir auch praktische Teile ein. Wer aus Hamburg und Umgebung kommt findet eine ausführliche Wegbeschreibung im Wiki des Attraktor.
The submission time for the Supplemental Wallpaper for Fedora 20 is now over, now there comes even a more hard part select the right ones for the package. As for Fedora 19 everybody who is member of a group additionally to the cla-group can vote. But there is something new this time, you can vote in Nuancier. That makes it a lot easier to vote, as you can see what you are going vote for and not have to look into the wiki like before. You will see voting with Nuancier is fun!
Nuancier is actually a thing why I love to work on Fedora, it took from the idea on Flock to this first working stage only a month. So I have to thank the people who helped to realize this idea. In the future Nuancier will not only serve for the selection process for the package, it will also serve for the submission process. We hope to have it ready for Fedora 21. With this it will become much much easier to submit to the contest and for me it will make it also easier as some things can be tested automatically on the upload. But enough with looking into an glass ball.
You can vote for at least 16 wallpapers, but you have not for 16 just select your favorites. The period for the voting will not be long just until 4th of October 2013 23.59.59UTC. If you want, you can get a badge for the voting but you have to claim it. All submitters will get one and the selected submitters another one, so a lot of badges to award. So now go for the vote and help making Fedora 20 become beautiful!
Es ist schon eine Weile her, dass eine neue Version von Inkscape erschienen ist. Die letzte Version 0.48.4 war eher eine Zwischenlösung und sollte die Wartezeit auf 0.49 verkürzen. Aber auch die ist nun schon etwas älter, jetzt steht aber scheinbar die nächste Version in den Startlöchern. Es ist also Zeit einen Blick auf die neuen Features zu werfen.
Die größte Änderung ist für den Endbenutzer nicht sichtbar, aber deutlich spürbar. Inkscape bekommt einen neuen Realtime-Renderer, der auf Cairo basiert. Das bringt nicht nur Performencegewinne auch sind einige der Renderfehler, die Inkscape bei Filtern und Musterfüllungen mit dem alten Renderer hatte Geschichte. Einziges Manko hier, sollte man Rastergrafiken in einer Grafik verwenden und diese kleiner skalieren müssen, kommt es beim Export dazu, dass dieses Bild etwas pixelig wird. Hinzu kommt das nun OpenMP-Multithreading für die Filter verwendet wird auch das bringt einiges an Performance. Hinzu kommt, dass Inkscape nun weniger Arbeitsspeicher benötigt, was das Öffnen auch größerer Dateien ermöglicht.
Neu ist eine weitere Ansicht und zwar im Graustufenmodus. Allerdings gibt es dafür ein eigenes Submenü – Farb-Anzeigemodus und das Umschalten ist statt Strg + 5 wie bei den anderen Anzeigemodi, Umschalt + 5.
Auch an der Oberfläche hat sich so einiges getan. So sind zum Beispiel alle fliegenden Fenster verschwunden, Fenster werden jetzt generell rechts angeheftet angezeigt. Massive Überarbeitung hat der Einstellungsdialog für Inkscape erfahren, hier sind die Möglichkeiten enorm angestiegen. So lassen sich beispielsweise die mitgelieferten Tastaturbelegungen jetzt direkt aus dem Einstellungsdialog auswählen. Damit fällt das überschreiben der default.xml weg.
Der Dialog für die Dokument Metadaten und der entsprechende Menüeintrag sind verschwunden, die Metadaten werden jetzt direkt in den Dokumenteneinstellungen eingegeben. Das dürfte einige wohl dazu bringen diese auch zu benutzen, bisher waren die Metadaten eher schwer zu finden.
Der Dialog für das Suchen und Ersetzen wurde überarbeitet, zusätzlich kann man jetzt nach Objekten mit gleichen Eigenschaften suchen.
Überarbeitet wurden aber auch die Dialoge für Text und Farbverläufe. Beim Textdialog werden jetzt oben die im Dokument benutzten Fonts angezeigt, dadurch muss man nicht mehr durch die bei manchen sehr lange Liste scrollen um bereits benutzte Fonts wieder zu verwenden. Das funktioniert nicht nur im Textdialog sondern auch in der Werkzeugeinstellungsleiste, bei aktiviertem Textwerkzeug. Falls der entsprechende Font nicht vorhanden ist und automatisch ersetzt wurde, wird er durchgestrichen angezeigt.
In der Werkzeugeinstellungsleiste für Farbverläufe ist ein Schalter für das Umkehren des Farbverlaufes hinzugekommen, diese Operation war bisher nur über die Tastenkombinaion Umschalt+R erreichbar und somit für die meisten Benutzer nicht vorhanden. Umfassender sind die Änderungen im Dialog, die Wiederholungsfunktion ist aus dem Dialog entfernt worden und nur noch über die Werkzeugeinstellungsleiste erreichbar. Dafür werden die bereits vorhandenen Farbverläufe direkt dargestellt und nicht mehr nur in einem Dropdown-Menü. Das ermöglicht ein einfacheres Umbenennen der Farbverläufe. Neu ist auch das in einer Spalte angezeigt wird, wie oft der Farbverlauf im Dokument verwendet wurde. Die Ansicht der vorhandenen Verläufe läßt sich dabei umsortieren, nach Namen, Anzahl auf oder abwärts. Etwas gewöhnungsbedürftig ist, das der Schalter für das Bearbeiten nicht mehr einen eigenen Dialog öffnet sondern in den Reiter für Füllungsfarbe springt und man dort die Farben verändern kann. Die Stoppunkte kann man auf dem Canvas oder in der Werkzeugeinstellungsleiste ändern. Dafür muss allerdings das Farbverlaufswerkzeug aktiviert sein, welches automatisch aktiviert wird.
Generell ist zum Dialog für Füllung und Kontur zu sagen, dass Slider und Texteingabefeld gegen einen kombinierten Slider ausgetauscht wurden, was sich am Anfang zumindest für mich trickreich gestaltet.
Auch am Ebenendialog wurde gearbeitet, so lassen sich jetzt die Ebenen auch per Drag&Drop verschieben, was sich allerdings trickreich gestaltet, da es nun auch die Möglichkeit von Sublayern gibt also Ebenen in Ebenen.
Was gibt es nun Neues an Werkzeugen und Optionen? Das Werkzeug welches wohl am ehesten auffallen dürfte, das es in der Werkzeugleiste hinzugekommen ist dürfte das Measurement-Werkzeug sein. Ein Werkzeug zum Messen von Strecken und Winkeln, viele Einstellungsmöglichkeiten gibt es hier nicht, nur die Maßeinheit der Rest ist intuitiv schnell zu begreifen.
Symbole als Element gibt es in SVG schon lange und jetzt gibt es sie auch in Inkscape. Symbole sind Grafiken, die einmal erstellt im Dokument in den Definitions stehen und beliebig oft im Dokument eingesetzt werden können, grob vergleichbar mit Klonen. Der Unterschied ist hier nur das über den Symboldialog diese auch per Drag&Drop oder Copy&Paste in das Dokument eingefügt werden können. Diese lassen sich im Bedarf in der Größe skalieren und auch rotieren. Die Sache hat allerdings noch einen Haken, bis jetzt kann man nur die mitgelieferten Symbole benutzen, das sind AIGA-, Karten-Symbole, Sprechblasen, Flowchart-Elemente und Logic-Symbole. Diese lassen sich zwar ergänzen mit eigenen Symbolen, in dem man eigene Symbole in das entsprechende Verzeichnis schreibt. Allerdings kommt man nicht darum herum das SVG von Hand zu editieren, eine Funktion wie bei Markern oder Mustern zur Umwandlung in Symbole gibt es bisher nicht. Hat man libvisio installiert so ist es auch möglich Visio Stencils zu verwenden, wenn man sie in eines der entsprechenden Verzeichnisse kopiert.
Neu ist auch das Werkzeug – Trace Pixel Art, welches eines der GSoC Projekte diesen Jahres war oder besser gesagt libdepixelize, denn darauf basiert diese Funktion. Sie ist speziell für das Tracing von Pixel-Art und liefert dem Original nähere Ergebnisse als potrace, welches hinter der Tracingfunktion in Inkscape steckt.
Eine neue Funktion erhält auch der Ausrichten-Dialog, mit dem man Objekte rotieren kann und die Stapelanordnung verändern kann. Darüber hinaus sind Teile des Ausrichtendialog über Tastenkombinationen erreichbar.
Neben diesen hauptsächlichen Änderungen gibt es noch eine Menge weitere, so lassen sich beispielsweise Hilfslinien mit einem Klich auf die Ruler an- und ausschalten, es gibt neue Extensions wie zum Rendern von QR-Code, fürs Fontdesign und zum Erstellen von GCode um nur einige zu nennen. Es gibt neue Import/Export Möglichkeiten und vieles mehr. Noch wird aber auch am Code gearbeitet und es wird noch eine Weile dauern, bis wir alle in den Genuß dieser neuen Funktionen kommen.
The Fedora Inkscape Unstable builds are now updated to the upstream bazaar revision number 12590. This updated development version of inkscape provides a range of bugfixes and updates. A full changelog of the changes between the previous build (12577) and this new build (12590) is available here.
These builds are now configured to enable the experimental dbus support that has been implemented in Inkscape recently. For more details on the dbus support in inkscape, I am also hosting a version of the dbus inkscape documentation here.
To enable this repo on Fedora follow the directions in the previous post about these builds. These builds are available for Fedora 18 (32bit and 64 bit), Fedora 19 (32 bit and 64 bit), and Fedora 20 (32 bit, 64 bit, and ARMv7).
The Fedora Inkscape Unstable builds are now updated to the upstream bazaar revision number 12577. This updated development version of inkscape provides a range of bugfixes and updates. A full changelog of the changes between the previous build (12500) and this new build (12577) is available here.
To enable this repo on Fedora follow the directions in the previous post about these builds. These builds are available for Fedora 18 (32bit and 64 bit), Fedora 19 (32 bit and 64 bit), and Fedora 20 (32 bit, 64 bit, and ARMv7).
In nur wenigen Wochen, vom 11.-13. Oktober ist es wieder soweit, die deutschsprachige Ubuntu-Gemeinschaft trifft sich in Heidelberg zur jährlichen Ubucon. Auch ich werde dieses Jahr wieder vor Ort sein, natürlich mit einem Workshop zu Inkscape. Von mir wird es aber auch dieses Mal einen Workshop zu Blender geben und zwar gleich am Samstag morgen um 10.00-13.00 Uhr.
Gemeinsam unternehmen wir die ersten Schritte mit diesem Programm und modellieren eine Szene mit Whiskyglas und Eiswürfeln und mit Hilfe der Flüssigkeitssimulation füllen wir das Glas auch mit Whisky. Dabei kommt Blenders neue Renderengine Cycles zum Einsatz. Alle Funktionen von Blender schaffen wir natürlich in diesen 3 Stunden nicht aber einige Grundlagen auf jeden Fall.
Wer dann von Grafiken noch nicht genug hat, der kann am Sonntag Morgen noch am Inkscape-Workshop teilnehmen.
Dort werden wir gemeinsam diese Szene mit Papier und Marker zeichnen oder zumindest wir werden es versuchen. Natürlich werde ich auch die restliche Zeit vor Ort sein, wer mich treffen möchte und noch nicht kennt, ich dürfte wohl ziemlich auffallen. Ich bin der Typ im Fedora-Shirt
Como ya es costumbre para mi, cada par de años me gusta cambiar un poco el estilo de la web. Primero porque me mantiene activa y segundo porque es una forma divertida de ver las cosas de siempre de forma diferente.
Esta vez, ya que me gusta mucho la forma en que el blog funciona, solo modifiqué el esquema de colores. Lo bueno de trabajar con css es que puedes hacer que un tema luzca completamente diferente solo con cambiar la combinación y unos pocos gráficos.
Espero les guste y cualquier sugerencia es bien recibida! A seguir blogueando!
Half of the submission period for the Supplemental Wallpaper for Fedora 20 is over now. Time to make a kind of status report. First we got so far a lot of submissions this time, nearly 90 and there is still more then 2 weeks left for submissions. Might be a lot of people just wanted to have the badge for the submission. The bad thing is the quality isnt this time so high as for Fedora 19 but there are still nice submissions, so we will get a nice package. This are my personally top 10 right now.
Another thing is I never had before to disqualify that much of submissions. The reasons are wrong sizes, simple to small and also wrong licenses. All of the submitters get in that case a mail from me and you should respond to it otherwise I have no chance as to disqualify it. Still a lot of people have problems with submitting to the wiki, mostly because the wiki cant create thumbnails when the file size of the upload is to big. Dont hesitate and ask me for help!
But for this problem there will be a solution soon, as I wrote in a past post here there will be an application for submissions and the voting in the future. The part for the voting is in a good shape now and it looks we can/will use it already for this period, I really looking forward to this. But for now still time for some more beautiful submissions until 30th September 2013 23:59:59 UTC.
So, the first time we talked about Hyperkitty recently, I mapped out the current Hyperkitty UI and we talked about future ideas. We also walked through a new mockup for displaying the directory of lists on the server (marked in blue on the diagram below.) Then, following that initial post, we talked about the design of Hyperkitty user profiles, which was one of those ‘future ideas.’ (I’ve also marked that in blue in the diagram below.)
Today we’re going to talk about another one of those future ideas – on the right of the diagram below you’ll see the ‘Tags & Category Directory’ and the ‘Category Overview’ areas, highlighted in yellow.
First, let’s talk through what categories and tags are, or at least, how they function in Hyperkitty today.
Categories are pre-set in the system – an administrator would have to add or remove categories, these are not something a user would be able to make up and apply to discussions. However, from the defined set of categories, any user can mark a thread with a given category. This brings up the next point: categories are used to categorize an entire discussion or thread… they don’t apply to single posts in a thread. Here’s a few example categories:
Tags are, well, tags – as you know them elsewhere on the internet. Users can use any tag they want and they can apply to individual posts in the thread. If you want to ‘tag’ a discussion, you could add a tag to the first post in the thread.
Why would people want to use these?
Well, first of all, traditionally the organization of mailing list archives is via list, month, and year. Unyieldingly so. What happens if a particular topic spans multiple lists? For example, perhaps the fedora-advisory-board list kicks off a discussion about the next upcoming Flock, then that moves to a flock-planning list, and then as the event gets planned, the design-team list gets involved in the T-shirt and collateral design, and the marketing list gets involved in getting the word out about the conference. Fast-forward to a year later, and it’s time to plan the next Flock. Wouldn’t it be great to be able to easily read through how things went down last year to see what worked and what didn’t, as to improve the experience this next year? You could tag all of the flock-related posts with the tag ‘flock,’ or you could try to push all of the threads into ‘Event’ category.
Now the scenario I illustrate above does rely on some manual intervention, in that someone involved needs to be using the web interface in the discussion and needs to make the effort to click on the category and/or tag controls to mark the discussions. (It would be cool to have tags automatically applied based on keywords in a post, maybe have a whitelist of terms we care about and if they appear they are added or suggested as a tag?) I think we need to see how categories and tags work a simple manual application model first, though, before we get too fancy. (What if we implement some kind of Bayesian filtering to automatically apply categories, for example? Hehe. But that’s a lot of work if the categories and tags feature doesn’t pan out to be useful, so let’s not waste the effort before we understand how things shake out first!)
We’ve gone into a bit of a tangent, though. Okay, so categories and tags could be a good way of bridging the barriers between lists when a topic spans multiple lists. They would make it easier for folks looking to easily access the history of a given topic. Why else would a user want to use categories or tags? Here’s a few more scenarios:
Certainly, though, the strongest case for both the category and tag mechanisms is easier future access of past discussions and this purpose is threaded through many of the example scenarios I give above. On a number of mailing lists I’m on – not just Fedora ones – I have noticed that topics come up sometimes in a cyclical nature. It’s hard to go back and look up the last time the topic came up to see how it was resolved (if at all) the last time. If someone asks a question that has been already asked and answered 359 times, categories and tags would make it easier to dig up a link with good reference information to point that person to. (‘Go search the archives’ in today’s mailman is a daunting thing to ask someone to do – you expect someone to manually scan subject lines month-by-month, year-by-year, if they even know which list to look under? Heh, I’ve done this before, but it sucks!! This is a good way to turn off newcomers!) If the information is easier to access, though, maybe we’ll find that people ask the same questions over and over less because we made it easier for them to find.
Well, hopefully there’s at least a partially good case here for having tags and categories, and we’ve got some decent use cases in mind for why they’d be useful. To the mockups, then?
In this screen you get a listing of all of the categories in the system. As noted above, these are static – you really have to be an admin of the whole mailman instance to add or remove these. These aren’t intended to change very often, but they could be customized per site. (By default though, they should come with a good stock set.) There’s a way to suggest a new category in the upper right, which should bring you to a form that might submit it to an admin panel somewhere.
Anyway, per category you can see per time period (here we’re looking at the past 30 days) the activity under each category. Click on the category, and you’ll get the Category Details page, which is next…
In this screen you can see what kind of information you can get about any single category. The example category we chose here is ‘Question.’ Per list on the mailman server, you’ll get a rundown of the discussions that were held under that category. You could filter it down to only view the lists you’re subscribed to in this list (see ‘My Lists’ button.) By default, it’s in alphabetical order per list, then in date order of most recent to oldest. You could click on the ‘Age’ header and view all across the lists in date order instead.
I’m still working on a tags overview mockup and tags details mockup. I’ve done the tags overview a number of different ways, but I’m still not happy with the results. What do you think – should we show tags as a tag cloud or a more simple directory like on ask.fedoraproject.org’s tag listing?
Also, what about composing tags? What if you wanted to see all posts that were tagged with both ‘fedora-art’ and ‘gears’, as in the example given above? How would you view that composition? What if you wanted to throw a category in the mix? Too crazy? Maybe provide the functionality through a RESTful interface and keep the UI bits simple?
I would love your thoughts and feedback on any aspect of this! I look forward to chatting in the comments
Recientemente tomé un ticket de diseño que solicitaba realizar un video descriptivo sobre como utilizar ask.fedoraproject.org. FranciscoD realizó un excelente screenvast y escribió una muy detallada lista de items a seguir, los cuales me ayudaron a editar y colocar audio (si, ya sé que aún no lo he hecho en español, pero por ahi vienen los subtitulos) que aunque con mi mal inglés, se entiende que es lo que hay que hacer.
Ya que pienso que compartir es bueno, acá está una lista de las herramientas que utilicé para realizar el video.:
recordmydesktop: usado para grabar el escritorio
inkscape: utilizado para realizar la simagenes que sirvieron de introducción y cierre
audacity: usado para grabar y editar el audio (el efecto de reducción de ruido funciona fantástico)
kdenlive: para juntar todo y agregar unos lindos efectos
While you still have to about the end of the month so submit your supplemental desktop backgrounds for Fedora 20, here are a few of my favourites that have been submitted (so far):
El equipo Fedora de Infraestructura está felíz de anunciar que keys.fedoraproject.org está activo y corriendo como un GPG keyserver. También somos parte del pool de sks-keyservers.net , lo que significa que las personas que utilizan pool.sks-keyservers.net serán direccionados a nuestro servidor.
Tenemos una interface web que fue diseñada por Maria ‘tatica’ Leandro Lombardo. Esto también permitirá promocionar fedora, ya que los usuarios de pool serán direccionados a nuestro servidor, el cual promociona el logo de Fedora y nuestro propio estilo.
El servidor puede ser accesado de las siguientes formas:
Puedes ponerlo también en: ~/.gnupg/gpg.conf:
GNOME 3.10 isn’t far off, and there’s a lot of cool new stuff coming. One of the most visible changes in this release is the new System Status Area. For 3.10 we have reworked this part of the shell, and in this post I’m going to give a bit of background on the process involved in designing and implementing it.
The System Status Area is our term for the section on the right hand side of the GNOME 3 top bar. This is the place where icons indicate how much battery you have left and the strength of your wi-fi network, and so on. It is here that you can also perform basic system-level actions, like powering off. One of the long-standing design goals for this part of the top bar is to consistently use it for system-level status and actions. This makes the area predictable and ensures a clean separation between applications and system.
During the 3.x GNOME series, the System Status Area received quite a lot of work as we sought to refine and mature the original design that was introduced in 3.0. These iterative changes definitely improved this part of GNOME 3. At the same time, the basic design didn’t change a huge amount and was quite similar to what we had in the GNOME 2 days: a series of small icons, each with a menu attached to them. Each icon represented a different aspect of system status (battery, wi-fi-, bluetooth, etc), and the corresponding menu provided actions that you could take in that area.
Over time, we realised that there were some limitations with this model. There were some relatively isolated issues, like the row of small icons being difficult click targets, not having a good place for a screen brightness control, and the network menu being overloaded with a lot of items. We also encountered issues with having the user’s name in the top bar. This created privacy concerns: the prominence of the name on the screen was uncomfortable for people using their machines in public places. It also presented layout difficulties in cases where people had long names.
There were also structural limitations with the old model. As we sought to refine the System Status Area, we started looking to more dynamic models for indicating system status, which would reflect user intent more closely. Bluetooth is a good example here: in the old model, a bluetooth icon would always be present, even if bluetooth wasn’t being used (or had never been used, for that matter). You might not be interested in ever using bluetooth, and yet this icon would always be visible.
The old design resulted in a status area that wasn’t as focused on the user as it could be. To improve on this, we wanted to only show status icons when a hardware capability is active or in use. This approach is also a much better fit for modes that involve multiple aspects of system status. Aeroplane mode is a good example here, since it can affect bluetooth, wi-fi and mobile broadband simultaneously. Having separate menus for each of these areas prevented us from having an elegant presentation system status.
As we encountered these issues, those of us who work on GNOME design started to think about possible solutions, and the idea of having a single aggregated menu for system status emerged. In January of this year, some early concepts were thrown around. Most of these were rejected, but as time went on we started to hone in on a solution that we liked.
It should be said that, since this posed a major redesign of a core part of GNOME 3, we didn’t rush into pushing for changes. Informal discussions took place over three or four months before we decided to take the plan forward, and we only did this after we were confident that the new approach would both work and be an improvement.
Once we were confident about the overall design approach it was time to get stuck into the details. Since we were redesigning how to handle the multitude of possible system states, this was a highly complex design task. I personally wanted to make sure that we had all the bases covered, and I embarked on creating a series of detailed wireframes that sought to cover the full range of possible system states that might be encountered. These detailed each aspect of system status, including the way each one varies. They also included a set of example scenarios which enabled us to see how the design would play out in practice. These detailed investigations revealed issues with the original designs and allowed them to be improved.
It was around this time that Jasper St Pierre – one of the main GNOME Shell developers – took interest in the proposal, and this enabled us to put the proposal to the rest of the GNOME community. In April we proposed the new menu design as a GNOME 3.10 feature, and asked for comments and feedback on the GNOME Desktop Development List. There was a lot of discussion about the feature, and we got a lot of feedback. Jon, Jakub and I discussed the issues that were brought up and made changes to the design to address them (we subsequently updated the desktop list about these updates).
Over the course of this detailed phase of the design process, a total of four major iterations of the mockups were produced. Each one was quite detailed, and marked an improvement in the design. If you are interested in this, you can browse the series of iterations in our design repository.
And then we were into implementation territory. I think we underestimated the amount of work involved in implementing the new design, and Jasper had to move mountains to make it happen. However, thanks to his hard work we are going into 3.10 with the new System Status Area as one of the new GNOME features that we’ll be introducing. As implementation took place we inevitably encountered design issues, and Jakub and I have been working with Jasper to resolve these as we encounter them. We are now testing the implementation and are busy tracking the bugs that need fixing before the release.
Having spent a while using the new feature, I have to say that I’m very happy with the way it has turned out. The System Status Area is now much more focused, and only contains information about things I care about. It is also really nice to be able to open the menu and get an overview of system status. The new menu is also much easier to use with a pointer. Before, you would have to consciously target one of the small icons as you moved the pointer towards it. With the new design, you can move towards the top corner without even having to look (it feels very similar to the Activities Overview hot corner in this respect). It is very Fittsy.
I’m also confident that the new System Status Area will serve as a good platform for making further improvements in the future. Now that we are able to deal with system status in a more dynamic manner, I think there will be interesting opportunties for innovation in this area.
As with any new feature, we will be closely monitoring the feedback that we get over the coming weeks and months, and I’m sure that there will be adjustments that need to be made. For anyone who does encounter issues with the System Status design, we have a new component you can file bugs against (called “system-status” – it can be found in the “gnome-shell” product). We’ll be keeping a close eye and are happy to talk through any issues you might encounter.
The process involved in developing this new feature has lasted about eight months, and we have put a lot of work into it. We think that the new System Status Area enhances the GNOME 3 experience, and we hope that you like it. We’ll also keep working on it in future releases, so that it gets better and better.
Tupi es un fork del proyecto KTooN creado para los artistas digitales interesados en Animación 2D, es una aplicación enfocada para niños de 8 a 100 años. Tupi es desarrollado en C++ utilizando librerías QT y es un proyecto de software libre bajo constante rediseño y evolución, liberado bajo licencia GPL (versión 3). Tupi provee un espacio para la creación y publicación de contenido animado.
Quizás sea la chica más feliz del mundo, ya que mi esposo me consiente cada vez que quiero instalar algo que no tiene paquete y el construye el rpm para mi. Así que, acá está el rpm, el cual ya ha sido creado por Maefloresta (creador de Tupi).
Fedora 19 x64 Tupi RPM: http://prdownload.berlios.de/tupi/tupi-0.2-1git02.fc19.x86_64.rpm
Otros releases y plataformas: https://developer.berlios.de/project/showfiles.php?group_id=12151
Ahora, ayudemos un poco a gustav y logremos que siga trabajando en este genial proyecto. acá está el anuncio oficial de su campaña kickstarter:
Tupi lanza su primera campaña KickStarter!
Luego de un mes de arduo trabajo realizando el video y preparando el contenido de la campaña, finalmente la gente de KickStarter nos dió luz verde para lanzar nuestra colecta más importante desde que iniciamos el proyecto.
La página oficial de la campaña está disponible en: http://www.kickstarter.com/projects/175927790/tupi-2d-animation-software-for-everyone
Una vez más necesitamos el apoyo de todos los artistas/usuarios al rededor del proyecto Tupi para lograr la meta de esta ambiciosa cruzada, este es un llamado a todo el mundo!
Todo lo que pedimos de ti, es que nos ayudes a difundir la palabra sobre nuestra campaña a todo aficionado al software libre que conozcas, a todo grupo de animadores 2D que conozcas.
Realmente apreciamos tu compromiso a nuestra causa, nuestro esfuerzo colectivo resultará en una mejor herramienta de animación 2D libre. MUCHISIMAS GRACIAS! :D
Design Software Special Interest Group (SIG in short) is born to fill the need of actively maintain packages related to design and include those unavailable in Fedora repository.
The SIG has a wiki located on https://fedoraproject.org/wiki/SIGs/Design_Software which contains information about the mission and its fonctions.