[freenet-dev] ground-up GUI redesign
Ian Clarke skrev: > I think our current problem is that despite our best efforts, the > current UI is built "from the code forward", rather than "from the user > back", and as such I think it is fundamentally flawed. Despite how much > we try, I think it is very difficult for us to put ourselves in the > shoes of an ordinary Freenet user, we are already too immersed in the > concepts and jargon of Freenet. One of the main issues (IMHO) is that modifying the current GUI is nearly impossible as a contributing user. There are no theme templates available to easily play around with. Last I heard was that you have to actually recompile Freenet if you want to make any GUI changes besides smallish CSS hacks :/. I think we have a long standing bug report somewhere about the implementation of a theming engine... - Zero3 (who is now writing from a new mail account)
[freenet-dev] ground-up GUI redesign
On Fri, Nov 20, 2009 at 1:31 PM, Christian Funder Sommerlund (Zero3) < lists at zero3.dk> wrote: > One of the main issues (IMHO) is that modifying the current GUI is > nearly impossible as a contributing user. There are no theme templates > available to easily play around with. Last I heard was that you have to > actually recompile Freenet if you want to make any GUI changes besides > smallish CSS hacks :/. > > I think we have a long standing bug report somewhere about the > implementation of a theming engine... > Yes, I think if Janie does this she will probably be replacing FProxy completely, not just creating a new theme. Ian. -- Ian Clarke CEO, Uprizer Labs Email: ian at uprizer.com Ph: +1 512 422 3588 -- next part -- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20091120/a0842858/attachment.html>
Re: [freenet-dev] ground-up GUI redesign
On Fri, Nov 20, 2009 at 1:31 PM, Christian Funder Sommerlund (Zero3) < li...@zero3.dk> wrote: > One of the main issues (IMHO) is that modifying the current GUI is > nearly impossible as a contributing user. There are no theme templates > available to easily play around with. Last I heard was that you have to > actually recompile Freenet if you want to make any GUI changes besides > smallish CSS hacks :/. > > I think we have a long standing bug report somewhere about the > implementation of a theming engine... > Yes, I think if Janie does this she will probably be replacing FProxy completely, not just creating a new theme. Ian. -- Ian Clarke CEO, Uprizer Labs Email: i...@uprizer.com Ph: +1 512 422 3588 ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Plugin auto-update: deploying the WoT etc?
Plugin auto-update is implemented and apparently working. More could be done to improve it, of course, but it looks like it should be sufficient for plugin updates to be released and deployed without having to deploy a new fred build to force them. New builds are distributed through USKs, just as with fred builds, and when they are downloaded, fred asks the user whether they want to update the plugin. If they say yes, we do a final check of the revocation key and then deploy the new version of the plugin. This should be enough for us to deploy WoT, Freetalk, and FlogHelper (and maybe more things e.g. digger3's IRC work?) as semi-official plugins, not bundled, marked as beta, but downloadable through the plugins page. Is it? (When) should I deploy these plugins? -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20091120/d4a73b09/attachment.pgp>
Re: [freenet-dev] ground-up GUI redesign
Ian Clarke skrev: > I think our current problem is that despite our best efforts, the > current UI is built "from the code forward", rather than "from the user > back", and as such I think it is fundamentally flawed. Despite how much > we try, I think it is very difficult for us to put ourselves in the > shoes of an ordinary Freenet user, we are already too immersed in the > concepts and jargon of Freenet. One of the main issues (IMHO) is that modifying the current GUI is nearly impossible as a contributing user. There are no theme templates available to easily play around with. Last I heard was that you have to actually recompile Freenet if you want to make any GUI changes besides smallish CSS hacks :/. I think we have a long standing bug report somewhere about the implementation of a theming engine... - Zero3 (who is now writing from a new mail account) ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] ground-up GUI redesign
My wife Janie, who (among other things) is a GUI designer, may have some free time over the next few months, and I'm trying to persuade her to attempt a ground-up redesign of Freenet's UI. She has built UIs in GWT before (to critical acclaim within her company), and I think this would be a good route for Freenet too. I think our current problem is that despite our best efforts, the current UI is built "from the code forward", rather than "from the user back", and as such I think it is fundamentally flawed. Despite how much we try, I think it is very difficult for us to put ourselves in the shoes of an ordinary Freenet user, we are already too immersed in the concepts and jargon of Freenet. The answer I think is a completely fresh perspective from someone that is unpolluted by existing Freenet concepts and jargon, who can focus on the user's needs to get stuff done, rather than our need to expose functionality. Janie has asked if we could put together a document describing the "use cases", basically the tasks that should be achievable from Freenet's UI from the user's perspective, but *not* simply a list of the functionalities that must be exposed. I've started a collaborative document here, all are welcome to contribute, but please read the notes at the top: http://etherpad.com/5GB8lyh5qD Ian. -- Ian Clarke CEO, Uprizer Labs Email: ian at uprizer.com Ph: +1 512 422 3588 -- next part -- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20091120/cbd09306/attachment.html>
[freenet-dev] ground-up GUI redesign
My wife Janie, who (among other things) is a GUI designer, may have some free time over the next few months, and I'm trying to persuade her to attempt a ground-up redesign of Freenet's UI. She has built UIs in GWT before (to critical acclaim within her company), and I think this would be a good route for Freenet too. I think our current problem is that despite our best efforts, the current UI is built "from the code forward", rather than "from the user back", and as such I think it is fundamentally flawed. Despite how much we try, I think it is very difficult for us to put ourselves in the shoes of an ordinary Freenet user, we are already too immersed in the concepts and jargon of Freenet. The answer I think is a completely fresh perspective from someone that is unpolluted by existing Freenet concepts and jargon, who can focus on the user's needs to get stuff done, rather than our need to expose functionality. Janie has asked if we could put together a document describing the "use cases", basically the tasks that should be achievable from Freenet's UI from the user's perspective, but *not* simply a list of the functionalities that must be exposed. I've started a collaborative document here, all are welcome to contribute, but please read the notes at the top: http://etherpad.com/5GB8lyh5qD Ian. -- Ian Clarke CEO, Uprizer Labs Email: i...@uprizer.com Ph: +1 512 422 3588 ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Plugin auto-update: deploying the WoT etc?
On Fri, Nov 20, 2009 at 5:47 AM, Matthew Toseland wrote: > Plugin auto-update is implemented and apparently working. More could be > done to improve it, of course, but it looks like it should be sufficient for > plugin updates to be released and deployed without having to deploy a new > fred build to force them. New builds are distributed through USKs, just as > with fred builds, and when they are downloaded, fred asks the user whether > they want to update the plugin. If they say yes, we do a final check of the > revocation key and then deploy the new version of the plugin. > > This should be enough for us to deploy WoT, Freetalk, and FlogHelper (and > maybe more things e.g. digger3's IRC work?) as semi-official plugins, not > bundled, marked as beta, but downloadable through the plugins page. Is it? > (When) should I deploy these plugins? > ASAP? Ian. -- Ian Clarke CEO, Uprizer Labs Email: ian at uprizer.com Ph: +1 512 422 3588 -- next part -- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20091120/d194650a/attachment.html>
Re: [freenet-dev] Plugin auto-update: deploying the WoT etc?
On Fri, Nov 20, 2009 at 5:47 AM, Matthew Toseland wrote: > Plugin auto-update is implemented and apparently working. More could be > done to improve it, of course, but it looks like it should be sufficient for > plugin updates to be released and deployed without having to deploy a new > fred build to force them. New builds are distributed through USKs, just as > with fred builds, and when they are downloaded, fred asks the user whether > they want to update the plugin. If they say yes, we do a final check of the > revocation key and then deploy the new version of the plugin. > > This should be enough for us to deploy WoT, Freetalk, and FlogHelper (and > maybe more things e.g. digger3's IRC work?) as semi-official plugins, not > bundled, marked as beta, but downloadable through the plugins page. Is it? > (When) should I deploy these plugins? > ASAP? Ian. -- Ian Clarke CEO, Uprizer Labs Email: i...@uprizer.com Ph: +1 512 422 3588 ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Plugin auto-update: deploying the WoT etc?
Plugin auto-update is implemented and apparently working. More could be done to improve it, of course, but it looks like it should be sufficient for plugin updates to be released and deployed without having to deploy a new fred build to force them. New builds are distributed through USKs, just as with fred builds, and when they are downloaded, fred asks the user whether they want to update the plugin. If they say yes, we do a final check of the revocation key and then deploy the new version of the plugin. This should be enough for us to deploy WoT, Freetalk, and FlogHelper (and maybe more things e.g. digger3's IRC work?) as semi-official plugins, not bundled, marked as beta, but downloadable through the plugins page. Is it? (When) should I deploy these plugins? signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
