google groups is dead?
Matteo 'Peach' Pescarin
I've recently stumbled upon John Resig article regarding how, more technically than personally, google groups has failed in his own job in creating an effective discussion group medium.
http://ejohn.org/blog/google-groups-is-dead/
I don't know what you feel about it, but as a mere user, I tend to agree.
The problem as you might imagine comes down to exporting existing messages, which John points out can be quite worrisome, and the other is about continuity of the service in the future.
All this post is because I would really be pleased to see grafx2 have a greater follow up and support.
Some people for example are suggesting moving over stackoverflow.com but I don't know how you're feeling about it.
The other bit, which I probably somehow care more, is the ticketing system of google code.
I won't say a thing about it as it's up to Yves and Pulkomandy to decide, but I was wondering if you were considering a switch over github or other more social systems (well github itself has its downsides and is very focused on code), but anyway something more usable anyway.
Best
--
Matteo Pescarin
pulko...@pulkomandy.ath.cx
On 2011-10-09 at 12:24:55 [+0200], Matteo 'Peach' Pescarin
> Hi all,
> I've recently stumbled upon John Resig article regarding how, more
> technically than personally, google groups has failed in his own job in
> creating an effective discussion group medium.
> http://ejohn.org/blog/google-groups-is-dead/
>
> I don't know what you feel about it, but as a mere user, I tend to agree.
> The problem as you might imagine comes down to exporting existing messages,
> which John points out can be quite worrisome, and the other is about
> continuity of the service in the future.
Well, I wasn't so annoyed by it so far. We're moderating the posts, which is
a bit annoying for users, but we're going to get about the same problem with
any mailing list system.
I'm not really willing to switch to a web-based system, for me it is much,
much more convenient to get the messages in my mailbox. I can process them
much more efficiently that way. I don't want to spend hours checking forums
for user messages (and I work on a lot of other projects besides GrafX2).
On the other hand, the google group never had a lot of users nor traffic. I
think people rather build small GrafX2 users communities in other existing
areas, like the PixelJoint forums. I can't possibly keep an eye on all of
them. I try to use Google Alerts for that, but I think it doesn't work very
well.
>
> All this post is because I would really be pleased to see grafx2 have a
> greater follow up and support.
> Some people for example are suggesting moving over stackoverflow.com but I
> don't know how you're feeling about it.
The same problem will likely arise from any 3rd-party service at some point.
Stackoverflow is raising today, and will fall down later, then maybe get shut
down. If anything, I'll host the sevice myself.
>
> The other bit, which I probably somehow care more, is the ticketing system
> of google code.
> I won't say a thing about it as it's up to Yves and Pulkomandy to decide,
> but I was wondering if you were considering a switch over github or other
> more social systems (well github itself has its downsides and is very
> focused on code), but anyway something more usable anyway.
I'm not fond at all of the "social" way for coding. We managed to include a
lot of features in GrafX2. I feel I'm quite open to user suggestions. We even
created svn branches at the request of some people (the "alternative gui" one
for Nintendo DS), and these never saw any commits.
Google Code allows for using mercurial instead of svn. As far as I can tell,
the result is a lot of clones of the original project, most of them adding
just a small bugfix (or even nothing at all). The clones get outdated, they
aren't synced in any way, and you end up with dozens of versions of the
software, all of them with different features and bugs.
While this may work well for projects like the Linux Kernel, where the core
team has been spending most of its time merging patches, I think there isn't
enough contributions to GrafX2 to make it useful in any way. If you made some
changes to GrafX2 sourcecode, most of the time we'll merge them in the main
tree. I don't think we ever rejected a patch.
As for the ticket system, well, I didn't see any problem with it. Anyone can
report issues/suggestions, and discuss existing ones. Do you think we're
losing users because of it ?
Google Code offers us a platform that doesn't need too much work to handle,
is fairly customizable, and easy to navigate. I hosted some projects on
soureforge and there, managing takes much more work to get everything setup.
Advertisements are a lot more intrusive, which I'm not really happy with,
either. I also had to find some stuff in github project, and I always get
lost in their website.
On the community, I'm not sure it's up to us to build it. I set up the tools
I needed to work on GrafX2, and that's about it. The google group is an easy
way to reach people knowing about GrafX2. I must admit in the end I don't use
it much, as I'm working more with individual people for the features I plan
to add. And people tend to send messages directly to me or Yves instead of
here. Seems the community will be elsewhere. Well, you know how to reach us
in case of problems :)
--
Adrien.
Psiweapon
Matteo 'Peach' Pescarin
pulko...@pulkomandy.ath.cx wrote:
> As for the ticket system, well, I didn't see any problem with it. Anyone can
> report issues/suggestions, and discuss existing ones. Do you think we're
> losing users because of it ?
well at the point of losing users, I don't know. After using several different ticketing systems I would say google's the most annoying I've found over the years. Although I'm a developer as well and my experience could differ from a normal user who know anything about ticketing systems at all. I don't even know whether a normal user would file a bug report, which kinda makes the point.
> Google Code offers us a platform that doesn't need too much work to handle,
> is fairly customizable, and easy to navigate. I hosted some projects on
> soureforge and there, managing takes much more work to get everything setup.
> Advertisements are a lot more intrusive, which I'm not really happy with,
> either. I also had to find some stuff in github project, and I always get
> lost in their website.
I had some projects as well on sourceforge, and probably ads and messy setups where some of the reasons why it started disintegrating over the years. I tend to agree with what you just said: I think one must always look for a balance.
> On the community, I'm not sure it's up to us to build it. I set up the tools
> I needed to work on GrafX2, and that's about it. The google group is an easy
> way to reach people knowing about GrafX2. I must admit in the end I don't use
> it much, as I'm working more with individual people for the features I plan
> to add. And people tend to send messages directly to me or Yves instead of
> here. Seems the community will be elsewhere. Well, you know how to reach us
> in case of problems :)
Again, I agree. Of course you as the creator of the program can only encourage community to aggregate providing some sort of "official" discussion board as this mailing list is.
How I see the grafx2 community is a small group of interested developers (apart the core team) and a good number of users. Of course it's not a big community although I don't see many users aggregating in forums to talk about what and whatnot of a specific program. Take pixeljoint for instance, I've never seen users talking much about the tools, rather more on pixelart itself. Most of the times are just posts announcing a new release of the program.
On the mailing list recently I've seen some really interesting techy posts about lua scripts and other stuff as well, and having your side of the story is imho very important as you know what's behind it and who actually things are working.
Regarding the social code side of the project, the power of being in a growing developer community means you can convey users to say the right things in the right place without too much of an hassle or registering or doing anything. But again I could be wrong, as google pretty much owns everything and pretty much everyone has a google account. Currently the most important thing for you is that you're happy with the ticketing system. Maybe being able to gather tickets from private messages into the ticketing system for everyone to see it would me nice (personally), also in order to understand milestones and such things.
Talking about this I was wondering if you ever considered having a proper homepage for grafx2 instead of the bare interface google code provides. I would guess your main idea is spending as less time as possible in setting things up.
--
Matteo Pescarin
pulko...@pulkomandy.ath.cx
On 2011-10-09 at 15:17:54 [+0200], Matteo 'Peach' Pescarin
> Regarding the social code side of the project, the power of being in a
> growing developer community means you can convey users to say the right
> things in the right place without too much of an hassle or registering or
> doing anything. But again I could be wrong, as google pretty much owns
> everything and pretty much everyone has a google account. Currently the
> most important thing for you is that you're happy with the ticketing
> system. Maybe being able to gather tickets from private messages into the
> ticketing system for everyone to see it would me nice (personally), also in
> order to understand milestones and such things.
It already works quite well this way : we quote mails by hand in the ticket
system as needed. For now, the trafic is quite low so it works well.
What I'm more worried about is the other way around. When I work on
something, I don't send an e-mail to this list, instead I ask some users what
they think about it, because I feel their advice will be helpful. Ilkke has
great ideas when it comes to defining the workfow and user interfaces of new
tools, Dawnbringer knows lua script writing and helps designing the API for
it, some other people know about C64 graphics format and so on. Maybe Ishould
just send everything to the list and get more advices.
>
> Talking about this I was wondering if you ever considered having a proper
> homepage for grafx2 instead of the bare interface google code provides. I
> would guess your main idea is spending as less time as possible in setting
> things up.
We tried to make the google code page an entry point with pointers to all the
stuff an user might be interested in. I admit the result is functional but
far from perfect. The news are gathered from a blog because Google Code still
doesn't offer a way to do it otherwise, and all the 'developper-only' stuff
tends to hide the user information somehow. We still have the same
documentation in the wiki and the built-in help, stored as two copies and out
of sync in many places. So I can't really say it works well. On the other
end, I'm not sure managing a separate website would fix all of it, and I
don't want to build one, I'd rather write some C code... Feel free to
contribute if you think you can :)
--
adrien.
Matteo 'Peach' Pescarin
pulko...@pulkomandy.ath.cx wrote:
> What I'm more worried about is the other way around. When I work on
> something, I don't send an e-mail to this list, instead I ask some users what
> they think about it, because I feel their advice will be helpful. Ilkke has
> great ideas when it comes to defining the workfow and user interfaces of new
> tools, Dawnbringer knows lua script writing and helps designing the API for
> it, some other people know about C64 graphics format and so on. Maybe Ishould
> just send everything to the list and get more advices.
I would second that :)
> We tried to make the google code page an entry point with pointers to all the
> stuff an user might be interested in. I admit the result is functional but
> far from perfect. The news are gathered from a blog because Google Code still
> doesn't offer a way to do it otherwise, and all the 'developper-only' stuff
> tends to hide the user information somehow. We still have the same
> documentation in the wiki and the built-in help, stored as two copies and out
> of sync in many places. So I can't really say it works well. On the other
> end, I'm not sure managing a separate website would fix all of it, and I
> don't want to build one, I'd rather write some C code... Feel free to
> contribute if you think you can :)
I'd love to, as a web devel I wouldn't mind contributing.
Of course setting things up with the right amount of automation would be nice, and probably we would need to dig a little bit further this aspect.
As I understand google code works well for the developers, but having something more nice for just graphic artists would be even better.
Behind it, from what you said and what I see on the website, you might need:
- about pages
- a news system
- a developers' blog
- a system for aggregating content from different other sources (?)
- have some sort of help pages (as it is the current wiki)
- an additional user provided contents area (tutorials?)
- a gallery.
- ?
--
Matteo Pescarin
pulko...@pulkomandy.ath.cx
> I'd love to, as a web devel I wouldn't mind contributing.
> Of course setting things up with the right amount of automation would be
> nice, and probably we would need to dig a little bit further this aspect.
>
> As I understand google code works well for the developers, but having
> something more nice for just graphic artists would be even better.
>
> Behind it, from what you said and what I see on the website, you might need:
> - about pages
> - a news system
> - a developers' blog
> - a system for aggregating content from different other sources (?)
> - have some sort of help pages (as it is the current wiki)
> - an additional user provided contents area (tutorials?)
> - a gallery.
> - ?
I think that's about it.
An about page with news and download is a good start (and not too hard to do).
what would be nice for the documentation/help is have at least part of it
kept in sync with the helpfile.h from the sourcecode. However, I fear that
this would lead to suboptimal results (for example, the inline help doesn't
feature pictures nor hyperlinks...).
The blog may not be used that much, news in the frontpage should be enough.
User-provided content would be nice, but so far we haven't seen much... (well
except the contests we did that had some entries). I don't like putting empty
sections onthe website :) Same apply for the gallery, I'd be very happy to
have more to show than the current set of screenshots... So far, user
provided content worked well for lua scripts and palettes presets, which is
easily shareable and reusable data. And you can't really build a community by
sharing palettes. Script do work, and a tip and tricks section would too.
--
Adrien.
Matteo 'Peach' Pescarin
pulko...@pulkomandy.ath.cx wrote:
> An about page with news and download is a good start (and not too hard to do).
> what would be nice for the documentation/help is have at least part of it
> kept in sync with the helpfile.h from the sourcecode. However, I fear that
> this would lead to suboptimal results (for example, the inline help doesn't
> feature pictures nor hyperlinks...).
>
> The blog may not be used that much, news in the frontpage should be enough.
>
> User-provided content would be nice, but so far we haven't seen much... (well
> except the contests we did that had some entries). I don't like putting empty
> sections onthe website :) Same apply for the gallery, I'd be very happy to
> have more to show than the current set of screenshots... So far, user
> provided content worked well for lua scripts and palettes presets, which is
> easily shareable and reusable data. And you can't really build a community by
> sharing palettes. Script do work, and a tip and tricks section would too.
I'll have a think and try to lay down a simple design to show during this week ;)
--
Matteo Pescarin
Matteo 'Peach' Pescarin
pulko...@pulkomandy.ath.cx wrote:
> An about page with news and download is a good start (and not too hard to do).
> what would be nice for the documentation/help is have at least part of it
> kept in sync with the helpfile.h from the sourcecode.
>
> The blog may not be used that much, news in the frontpage should be enough.
>
Ok I've worked out something sufficiently simple that should be able to contain the desired stuff. This means something that is more practical and usable rather than pure aesthetic pleasure.
I've tried to work as much as possible with the colours found in the logo (which was quite challenging), and used some other pixel-like elements, giving a bare bone we could work on and improve.
Still we should have a better though about the different sections and see what's best to include.
In the design (don't expect too much as I've had roughly 1 or 2 hours to put this down during this week) as you can see I've used a web font (taken from google web fonts repository) that can be used for headings that can be replicated in the same way as it has been done on page1 (supposedly the index) to provide a nice run-in to the page whilst being informative.
Personally I tend to like the right informative column (or at least the separation that provides to the main content area) but I'm not particularly sure how it could be filled in in the remaining pages.
> Script do work, and a tip and tricks section would too.
Regarding the scripts and tips & trick could you tell me how would you expect it to be working? something like a simple list of items that expands/downloads the content?
Is there any example I can see of tips and tricks?
If I imagine them to be (one sentence, not too long) it could also be possible to have a single suggestion appear randomly with the run-in font of the homepage in the same section, as "featured" content.
Well I'm maybe leaving too much to the imagination now, but I would definitely work on a better design trying to improve what we have based on your suggestions and critiques so that the implementation can be quick and without doubts on what to do.
Implementation-wise, consider that building a news section is really easy, and adding some sort of automation via php to parse an RDF and build, for example, the content for the download pages, is not a problem at all. Whether having the ability to customise this stuff is completely a different matter.
http://peach.smartart.it/private/grafx2/page1.html
Best,
Peach
--
Matteo Pescarin
Yves Rizoud
Don't feel compelled to stick to icon colors, the origin is an icon
with EGA palette, very few nice colors to choose.
> what would be nice for the documentation/help is have at least part of it
> kept in sync with the helpfile.h from the sourcecode.
text format, including the default keyboard settings. Then I can set
the makefile to automatically regenerate that file when helpfile.h is
touched.
> Is there any example I can see of tips and tricks?
http://code.google.com/p/grafx2/wiki/TipsTricks
Most where written by X-Man for the MS-DOS version, they still apply
(but the ascii art is broken). I originally wanted to keep them until
somebody writes something significantly better, but if they seem to be
a burden when writing fresh new documentation, don't bother.
Same with the FAQ : Most is from the original documentation.
I have no idea of short tips/tricks, beyond the two I keep repeating :
- press F1 in a window or on a menu icon, to see what it does and view/
redefine keyboard shortcuts
- right mouse button very often has a different function.
> Implementation-wise, consider that building a news section is really easy, and adding some sort of automation via php to parse an RDF and build, for example, the content for the download pages, is not a problem at all. Whether having the ability to customise this stuff is completely a different matter.
links.
If I understand well, you already plan on including dynamic RSS
content ? It would be great for automatic integration of data from
googlecode and the blog.
On googlecode I had a hard time setting it up, it's a very ugly
javascript gadget.
Yves
Matteo 'Peach' Pescarin
Yves wrote:
> Peach, this design is wonderful.
> Don't feel compelled to stick to icon colors, the origin is an icon
> with EGA palette, very few nice colors to choose.
Thanks a lot, I've tried introducing a warmer colour as orange, but I would stick to the colours you see now as it seems they're pretty much in a balance.
The only one I could possibly bring up in lightness is the violet/purple.
> I can very easily make the program export its own helpfile into any
> text format, including the default keyboard settings. Then I can set
> the makefile to automatically regenerate that file when helpfile.h is
> touched.
what kind of formats do you think you can provide?
Are we talking about this?
https://docs.google.com/View?id=dcbq959n_4dzgxwp83
I wonder how would it be published, as it could impact the way it's taken into the website.
A solution to this could be to write an XSLT to convert it so that it could be grabbed straight from the code.
To be more precise we would need to understand:
1) Ways to publish it (url, zip pack, ..) and steps to do that
2) Starting formats (XML, text, ..)
And give this we can work out how to include it into the website (simple inclusion without modifications, some modifications to be done, manual pasting... ?)
> > Is there any example I can see of tips and tricks?
> I think Pulkomandy was already referring to the ones we have :
> http://code.google.com/p/grafx2/wiki/TipsTricks
> Most where written by X-Man for the MS-DOS version, they still apply
> (but the ascii art is broken). I originally wanted to keep them until
> somebody writes something significantly better, but if they seem to be
> a burden when writing fresh new documentation, don't bother.
> Same with the FAQ : Most is from the original documentation.
Ok so the easiest would be to make two simple title+body pages with nothing more.
Otherwise we can have this other solution for the FAQ:
on the backend you can enter one or multiple questions and relative answers.
You can also think about grouping them into categories (think about legal stuff, OS-related, etc)
And for the Tips and Tricks, something similar to the first one but just single lines (with maybe an image attached to it?).
> I have no idea of short tips/tricks, beyond the two I keep repeating :
> - press F1 in a window or on a menu icon, to see what it does and view/
> redefine keyboard shortcuts
> - right mouse button very often has a different function.
We can see if we want to implement something more fancy we'll have a go.
> I expect Downloads to be a "free" page, manually edited for text and
> links.
Ok, I presume that's the same way you publish the download list on the google website.
> If I understand well, you already plan on including dynamic RSS
> content ? It would be great for automatic integration of data from
> googlecode and the blog.
> On googlecode I had a hard time setting it up, it's a very ugly
> javascript gadget.
Shouldn't be a great problem, it's just grabbing an RSS from an URL, parsing it and converting to something that could be displayed on the website, nothing particularly difficult at all.
On top of that, have you ever thought about getting grafx as a domain name? as it seems to be currently available ;)
--
Matteo Pescarin
Yves Rizoud
what kind of formats do you think you can provide?
The origin is this C file, too hard to parse directly and you wouldn't get the default shorcuts : http://grafx2.googlecode.com/svn/trunk/src/helpfile.h
Are we talking about this?
https://docs.google.com/View?id=dcbq959n_4dzgxwp83
At the moment we repeated them as Wiki pages: http://code.google.com/p/grafx2/wiki/ManualSidebar
It's the side menu that you get for the page http://code.google.com/p/grafx2/wiki/UserManual
The text is hard-formatted for 44 characters.
I don't know, at the moment we haven't really used the strength of the wiki form, maybe it would be best to simply refresh these pages once, and then improve them with images of the icons and windows, actually link to pages whenever a important word is used (Brush, Palette, Effect, Menu)...
Ideally, images would work as image maps, so that when you click a button/icon it navigates to the relevant info, but googlecode wiki doesn't support them.
Matteo 'Peach' Pescarin
Technically speaking I'm using Yii php framework (which in turns uses Blueprint as CSS framework).
Now I'll be developing the whole thing in my spare time, once I've got something minimally usable, I'll be sharing it on github (if that's not a problem) so anyone who has the ability can help me with it, and then deploy it on my own website (was thinking of grafx2.smartart.it as I still got one subdomain available).
Once the website is feature complete we could think about having its own host and hostname as well (as I said grafx is available, just saying and I won't even bother buying it).
Let me know what you think, for anything else, just ask me. :)
--
Matteo Pescarin