Wow - that's great news! Sorry I missed/misread/forget your earlier email -
mea culpa there.
Let me address your points individually so we can start to scope the work.
1) We already have a rudimentary "one-button" namespace creation
routine. It lives under the /admin pages. It's not awesome, but what
specifically about it would you like to see change?
2) Using a dropdown approach is going to be problematic. I understand
why you want this, but the stuff that deals with usernames is totally
decoupled from the FlexWiki bits (it's just straight .NET authentication) to
enable us to easily authenticate against whatever store wiki administrators
want to use - Windows authentication is just one possible store. How
important is this scenario to you?
3) We have a control panel in the form of the /admin pages. It could
use a lot of work, though. I think identifying the areas of the config file
that can't be modified via the controls already present and figuring out
which of them need knobs and buttons shouldn't be too bad.
4) Done.
Regarding timeline, my thinking is that the above changes are likely to wind
up in a post-2.0 release. The multi-year gap between 1.8 and 2.0 is
something that shouldn't happen again - I'd rather see a new version every
few months. So I'd rather see 2.0 as changes to the core engine plus the
stuff that we already have in motion. We kick it out the door then start
shipping features - including improved administration - in a tighter loop.
My reasoning here is that we're moving forward with a bunch of stuff, and
the idea of improved administration - while good - is pretty late in the
game when we've already made our current users wait a really long time for a
new production-ready version. I'd really rather serve them than potential
new users, especially as we're not a commercial product and have no pressure
to grow our "market".
But perhaps we can get a plan in place that addresses some or all of your
concerns consistent with a near-term timeline. Specifically, if you can live
without dropdown user selection, it might be reasonable to get the rest
done.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Qasper
sales
Sent: Wednesday, August 08, 2007 5:01 PM
To: 'FlexWiki Users Mailing List'
Subject: Re: [Flexwiki-users] Shipping FlexWiki 2.0 - Proposed Feature List
Yeah, I did respond. I said that we don't have the needed talent to help but
that I would gladly outsource the completion of all these items if one of
you folks with depth and experience would kindly take a few hours and
document what the steps are.
I'll be happy to contribute.
Fred
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Craig
Andera
Sent: Wednesday, August 08, 2007 4:17 AM
To: 'FlexWiki Users Mailing List'
Subject: Re: [Flexwiki-users] Shipping FlexWiki 2.0 - Proposed Feature List
So, it would be great to do all the things you mention. None of them,
however, are present in FlexWiki 1.8. So we're not making it any more
difficult than it already is.
You never responded to my earlier suggestion that your company donate some
of your developer's time to address some of these issues. Is that something
you're able to do? Given that you want to integrate FlexWiki into your
commercial product, then it doesn't seem like an unreasonable tradeoff to me
that some of your company's resources would go into making the changes you
suggest. Of course, I understand if that's not feasible for you, but then I
expect you'd understand if the volunteers here don't choose to implement to
your specifications.
So while your comments are appreciated, my recommendation to the community
continues to be "release as outlined in my proposal".
Also, "upload and go" functionality is already there. Create a virtual
directory, unzip the full web distribution, and you're off and running on
most systems. Database not required. Accessing the config file not required
for simple setups. Controlling read permissions is also handled.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Qasper
sales
Sent: Tuesday, August 07, 2007 11:20 PM
To: 'FlexWiki Users Mailing List'
Subject: Re: [Flexwiki-users] Shipping FlexWiki 2.0 - Proposed Feature List
Hi All,
I'm not sure where our company's needs are met in the 2.0 release, but
please let me list the critical things we are after. I really commend you
folks on what you've done, but I suggest you sit back and look at the wiki
from a small/medium-size business user's viewpoint.
I hope to convince you NOT to release RC1 until FlexWiki is made more
user-friendly. I'm sure the underpinnings and structure of FlexWiki are
great, but I'm imploring you to ensure that the average computer user can
easily install and use FlexWiki, without resorting to low-level editing of
config files, as well as some of these points... sorry for the rambling, but
I think you won't get any growth in this product until you mainstream it.
1. First and foremost: end-user creation of namespaces - what we call
projects - through a control panel. I've mentioned this before. For
business, the success of a Wiki lies in its ability to provide groups of
pages that only a select group of people can view and, further, only a
subset of that group can have write privileges. I believe the latter is
handled, but I would like to get feedback on the former.
A Wiki as an information source is great, but unless it provides a practical
solution to a real business need, its adoption will be limited. There has to
be a compelling reason for a business to go to the trouble of implementing a
Wiki. I'm fully aware that some businesses will implement FlexWiki, but
FlexWiki has potential in thousands of businesses.
For example, I, as a FlexWiki user, should be able to start a new project
simply by clicking a button and naming the project - anything more
complicated just won't make it. Once the project is started and the home
page for that project is initialized and displayed, I can set who can use
the project.
Requiring a user to actually edit any type of config file is far too techy
and simply not acceptable in today's software world. Users should be able to
click and go and all settings should be able to be done through a control
panel.
2. Setting the user authority. Any page that I want to designate as
customized for read/write privileges should allow me to access a central
page popup with a dropdown list of users where I can click the user I want
and select an authorization type from a pick list, so that I can just point
to a user, select an authority (read, write, etc.) and have that info
auto-inserted onto the wiki page.
Nobody should be be expected to remember user names in a company of dozens
or hundreds of users..
3. Simple implementation. One of the things about .NET implementation is its
simplicity. The new version should not require me to access any config file
in order to specify settings or conditions. That's simply too complex for
any small/medium size business. I should be able to simply copy the files to
the server and start using the Wiki.
It's really important that you take the time to implement a control panel. I
urge you not to even consider release until a full control panel is there.
Several similar wikis recognized this and have implemented excellent control
panels.
I think it's Perspective that has really stretched out and produced a great
control panel. Have a look at it.
4. The new version should offer non-databased functionality, like 1.8 has. I
don't know if it does, but, again, the idea is to make it easy for a
business to just upload the Wiki files and start using it.
We are www.Qasper.com and we target small and medium-sized businesses. Many
of them would love an easily-implemented Wiki. Initially we started working
with FlexWiki and implemented it in several client sites, but recently we've
moved to another product because FlexWiki is too hard for an end-user to
user and it doesn't provide project functionality. We would dearly love to
return to FlexWiki.
I previously mentioned the following quote:
"We use TWiki internally to manage documentation and project planning for
our products. said Eric Baldeschwieler, Director of Software Development of
Yahoo! Our development team includes hundreds of people in various locations
all over the world, so web collaboration is VERY important to us. TWiki has
changed the way we run meetings, plan releases, document our product and
generally communicate with each other. We're great fans of your work!"
Note the comment on "manage documentation" and "project planning". These and
collaboration are three of the biggest needs of business today.
I urge you not to release FlexWiki until these issues have been strongly
considered and debated. If you release 2.0 without ease of use, simple
implementation of project functionality, and easy implementation of user
restrictions, you will get a reponse of "more of the same" from many of the
potential users. You may appeal to developers and programmers, but it just
won't make it into the mainstream.
You've put a lot of effort into building a solid V2.0. Please, take the time
to build a strong end-user interface.
Regards,
Fred Dalgleish
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Craig
Andera
Sent: Tuesday, August 07, 2007 6:19 AM
To: 'FlexWiki Users Mailing List'
Subject: [Flexwiki-users] Shipping FlexWiki 2.0 - Proposed Feature List
Now that performance looks like it's more or less where it needs to be, I
want to get consensus on what constitutes FlexWiki 2.0 RC1. Here's the list
of things I can think of that need to be fixed or added:
. Address outstanding SQL Server bug reported here.
. Address outstanding search page bug reported here.
. Complete new stylesheet work.
. Complete or partially complete XHTML compliance work.
. Add administration page for working with new cache (clear items,
view cache, etc.)
. Add administration page for working with new configuration file
format (reload config, edit config file online, etc.)
That's a fairly short list, which is very good! Can anyone think of anything
else that I'm forgetting that should go into 2.0 RC1?
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Flexwiki-users mailing list
Flexwiki-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flexwiki-users
