Website technology: sure, I agree. But its always best to use apache technology :) Since the website will be centered on a client, you are going to have to use .NET or Java. Since .NET requires Microsoft licenses, I think that leaves us with Java...
wire frames: No, I do not have any. Im thinking just some basic screens and forms will do. SVN: .NET and java clients: https://svn.apache.org/repos/asf/incubator/devicemap/trunk/devicemap/ javascript browsermap client: https://svn.apache.org/repos/asf/incubator/devicemap/trunk/browsermap/ OpenDDR data: https://svn.apache.org/repos/asf/incubator/devicemap/trunk/data/ So if someone wants to take a stab at the website, just announce what you plan on doing here on the list so people are aware and can coordinate as needed, and as always show progress. When you get a good prototype up and running, we can review and then if all is good, migrate it into the project and then discuss how we move everything further (ie roadmap). Thoughts? ________________________________ From: venkata kiran surapaneni <[email protected]> To: [email protected]; Reza <[email protected]> Sent: Saturday, April 5, 2014 12:34 PM Subject: Re: Better documentation. Hi, I agree with the use cases proposed. I don't think the technology used to create the website matters. It can be .net, Spring MVC or any thing. I think the convenience of the developer who ever takes the responsibility should be deciding factor for now. When the library is released and is doing good, if required the website can be modified if required. I don't think this website is complex. I think some one needs to create a wire-frame sketches on how the website would look so that every one can have a look at them and provide the feedback. It would make the life easier for who ever is implementing the web site and reduce rework. While we are discussing the options to make this library more user friendly, I think we need to look at the code bases also. The structure in which they are committed to svn are confusing(partly make be due to lack of documentation). If possible each component in this should have its own repository. Is this some thing that can be considered ? Thanks, --Kiran
