Geez, what's in your coffee? I didn't ask for anyone in the "community" to
volunteer. I offered to pay the whole cost of implementing these
user-friendly features out of my pocket through outsourcing...
All I asked is for someone with deep knowledge to set out the steps on
implementing them so that I can get the job done. It's far more efficient
for someone who is very familiar with FlexWiki to spend a little time
detailing how we would do the work than for me or one of us to spend dozens
of hours getting into the source code.
Thanks for the caustic comments.
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Derek
Lakin
Sent: Monday, August 13, 2007 2:34 AM
To: FlexWiki Users Mailing List
Subject: Re: [Flexwiki-users] Shipping FlexWiki 2.0 - Proposed Feature List
On 8/13/07, Qasper Tech Support <[EMAIL PROTECTED]> wrote:
Hi Craig,
I am unable to log into the current version - once log in fails (because I
don't have an account), I'm locked out completely so I can't look at the
"one-button" namespace creation.
For obvious reasons, the general public don't have access to the
Flexwiki.com Admin pages. You could always download a copy of FlexWiki,
install it yourself, and examine the admin setup yourself.
Re: 2 - using Windows authentication is way too tied into Windows. In most
end-user apps, the users register into a database table. That offers
significant flexibility to the app and allows it to work outside Windows
control. It's critical, IMO, to a successful, independent wiki.
As Craig pointed out, "Windows Authentication is just one possible store"
for authentication. We use standard ASP.NET authentication, which is then
outside of FlexWiki. You can implement whatever authentication you like. If
you use IIS7, you can even administer the ASP.NET Authentication database
from within IIS Manager.
If dummies like me and a couple of my crew can do the whole www.Qasper.com
<http://www.qasper.com/> thing, including some fairly complex user
registration, it should be easy for you guys to spec a method I can
outsource. You know the inner workings of FlexWiki. Start where the login
appears - reroute it to a pop-up page that ties to a database. Can you
detail that for us?
If dummies like you and your crew can "do the whole www.qasper.com thing",
then I'm sure you can work out how to use ASP.NET authentication with
FlexWiki.
Re: 3. Can you detail the requirements so that I can outsource it, please?
Perhaps a more valuable contribution to this open source project would be
for you to detail some requirements that the community could review and
provide feedback on. Once that is place you might actually find some
volunteers to do the work.
_____
From: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
[mailto:[EMAIL PROTECTED] On Behalf Of Craig
Andera
Sent: Thursday, August 09, 2007 7:07 AM
To: 'FlexWiki Users Mailing List'
Subject: Re: [Flexwiki-users] Shipping FlexWiki 2.0 - Proposed Feature List
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]>
[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]
<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]>
[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 <http://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]
<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
<https://lists.sourceforge.net/lists/listinfo/flexwiki-users>
-------------------------------------------------------------------------
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
