Gossamer Forum
Home : Gossamer Threads Inc. : Discussion :

Gossamer Threads Development Survey

(Page 1 of 4)
> >
Quote Reply
Gossamer Threads Development Survey
Hello everyone,

(This post is a follow-up to the Gossamer Threads Development post in the Announcements forum. If you have not already done so, please read that post first.)

To ensure that the development process of Gossamer Threads products meets your specific needs as much as possible, we encourage you - our users, clients, and customers - to respond to the following short survey regarding the direction the Gossamer Threads product development team should take for future product development. Feel free to be as brief or verbose as you like in responding.


  1. What do you think of the XHTML+CSS design described in the announcement? Do you think this is a good or poor move, and do you have any suggestions, alternatives, or other ideas that we might consider?

  2. How important is backwards compatibility with older browsers to you? When we say compatibility, we are talking about extremely old browser versions - that is, Netscape 4 and IE 4 - which already are incapable of displaying much of what is on the internet successfully.

  3. Are you generally opposed to or in favour of using javascript to add functionality? Up to now, we've taken the policy of using javascript to augment existing capabilities or provide convenience features, with some notable exceptions such as the advanced editor in Gossamer Forum and Gossamer Mail. In the new versions however, we are planning some features that absolutely require javascript in order to work rather than to simply augment existing capabilities.

    To give a specific example, one of the features we have already added in the v3 development code is a javascript-based spellcheck feature allowing you to correct your spelling by clicking on misspelled words, then clicking on a correction to replace it with. In this case, how acceptable would you consider having the spellcheck support only available to users with javascript enabled in their browsers? We will never make core features (e.g. sending e-mail, reading posts, adding links, etc.) require javascript, but making secondary features such as this that rely on javascript support makes it much easier for us to quickly add features, and often allows those features to work better for the end-user.

    Not having to support both javascript and non-javascript versions will free up time otherwise spent coding and maintaining both versions which will allow us to spend more of it working on new features for our programs. Additionally, it will keep the templates and the code cleaner without extra 'duplicate' code.

  4. What suggestions do you have, if any, for the product manuals? Do you find the current format (PDF) useful, or would you consider that we make the manual available in another format, such as MS Word (.doc) or perhaps even broken down into multiple HTML pages?

  5. Have you had any problems with the installation of our products? How can we improve the installation process? Would an installation tutorial be useful?

  6. We're considering adding a "tutorials" section to the product pages of our website to cover various common tasks associated with administering our products comprising items such as installation (question 5), a Getting Started Guide (e.g. for Gossamer Forum, how to create a Category and Forum), making simple template modifications, etc. Do you feel this addition would be useful, and if so, are there any specific areas in addition to the above that you would like to see?

  7. Are there any specific weak spots in our programs currently that you would like to see addressed, with respect to how the overall programs work? We do not refer here to individual product feature requests for this question - but rather areas that affect all of our programs, such as installing, modifying templates, upgrading, etc.




Any other comments and suggestions you care to offer regarding the v3 development would be greatly appreciated. We obviously can't make any promises to include every feature/suggestion, but we will seriously consider and try to respond to each one in a timely fashion.

Gossamer Threads Development Team
Quote Reply
Re: [GT Dev Team] Gossamer Threads Development Survey In reply to
Hi,

the changes you're going to make seem to be very nice.

As I've read, your going to implement an auto-update feature for LSQL. I think you should make it optional, so an admin can switch the auto-update-function of the software on or off.
Also a list of auto-updated files should always be available, so if someone has made e.g. hardcoded mods, he/she gets to know, that his modified file was overwritten by a new update and is informed that he has to do the mod again.

The (LSQL/Forum) email/newsletter-functionallity should be developed:
A possibility of using eMail-attachments would be very nice.
Also some kind of newsletter/mail-bounce-handling would be very great!
At last the newsletter-subscription-functionallity should use an double-opt-in.


LSQL-Categories:
It would be very nice, if it'll be possible, if the admin could exclude categories from link-submitting.



Cheers,
Manuel

Regards,
Manu

Shopping Portal Shop-Netz.de® | Partnerprogramme | Flugreisen & Billigflüge | KESTERMEDIA e.K. | European Affiliate Marketing Forum.

Last edited by:

ManuGermany: Nov 15, 2004, 3:41 AM
Quote Reply
Re: [ManuGermany] Gossamer Threads Development Survey In reply to
Flagging categories as visible or not, should be implemented in LSQL...


What about existing plugins? Will they keep on working in the 2005 versions?

Last edited by:

nt6: Nov 15, 2004, 4:21 AM
Quote Reply
Re: [GT Dev Team] Gossamer Threads Development Survey In reply to
CSS - I see this one as self-evident. It's a good idea.

Javascript - tough one, but all things considered I think it adds more than it disrupts, so to use javascript extensively is a good idea. This would have been different a few years ago. It will also be different a few years from now (ie javascript issues probably won't be a concern, in the same way other Web technologies are now standard), so I think that is a good indication to forge ahead with javascript features (even for useful and important features like the spell check you mentioned).

What are the statistics for Internet users with or without javascript?

Formats for manuals - I'd say use all three, PDF, HTML and MS Word. I don't want to be presumptious, but I wouldn't have thought the overheads in time would have been that bad having to update all three. Personally, I rarely use PDF, preferring HTML for my online software. I only tend to use doc or txt files when I'm installing software on my home machine. A short txt file explaining the basics after I've unarced Gossamer Mail is sufficient for me, with the main documentation online.

Installation - my feeling has been to wait for a while after a product is released. I would always read numerous bug reports in software updates. It always seemed a bug fix for the bug fix was released, so it made sense to wait before installing an update.

The templates have always been a major gripe for me. In a couple of the forums for example, I found a tendency for some users to be defensive about the software when a suggestion to improve the templates was made. I can see what might motivate them, but rather than supporting the product, I think this is counter-productive in the long run. I've always thought the look and feel of GMail and GForum (the two pieces of software I use) would benefit enormously from a complete makeover. It needs to hold its own against the likes of Yahoo mail, in terms of professional look, graphic design and attention to detail. I don't think it helps the software for users to follow up these comments by nit picking the design of the competition, or pointing out the templates can be modified by hand to make them look how you want. These comments defend the status quo, but don't acknowledge that the design can be vastly improved. Personally, I think designing the templates to work in popular and widely used software like Dreamweaver is a must. This is entirely possible, no matter how complex and convoluted the templates, as I do it myself with scripts that make dynamically created content.

Jason
Quote Reply
Re: [GT Dev Team] Gossamer Threads Development Survey In reply to
CSS - the only thing that worries me is table elements.

CSS is great for font stuff, colors, and things like that, but for tables it's still pretty much cutting edge. I'm not sure if you intend to use css for tables, but I thought I'd throw this in.

Cheers Smile

------------------------------------------
Quote Reply
Re: [GT Dev Team] Gossamer Threads Development Survey In reply to
1) I've wanted to do this with my GMail install for some time now. I think this is definitely the way to go for the future.

2) Not very. I think 5 and up would be more than adequate.

3) I've never liked using JavaScript in any of my applications but there are times when you just need to. I think as long as you can keep it out of core features like you mentioned it would work for me. I do like the added functionality in your example and I think I could learn to be more open minded about it. Are you noticing people turning of JS for security reasons at all?

4) I like PDF the best myself. I would, however, like to see the manual as HTML in the application as well. But what would that do to the download size of the app?

5) Not personally. But I think more info on file permissions and other common problems (images in the cgi-bin) would help alleviate some support time on your end though.

6) Yep, see #5. This would be a good area to cover a lot of your common support problems that can really be taken care of by the end user doing a little homework. A FAQ in addition to tutorials would be nice.

7) With the Plug-in system (which I really enjoy) such a big part of your applications I would like to see better, more up to date, POD in your modules. I would also like to see a section on your website for the HTML versions of the POD. It would also be nice to see some of your core modules released on CPAN. I think GT::Template is just awesome but I can't use it as often as I would like :) And I just can't find anything close to GT::SQL.

In lieu of releasing your GT::* modules to CPAN would you be open to some sort of a developers license?

Thanks,
Charlie
Quote Reply
Re: [ManuGermany] Gossamer Threads Development Survey In reply to
In Reply To:
Hi,

the changes you're going to make seem to be very nice.

As I've read, your going to implement an auto-update feature for LSQL. I think you should make it optional, so an admin can switch the auto-update-function of the software on or off.

We won't (currently) make this automatically download and install updates. Our current thinking is more along the lines of having the admin panel check for and list updates on the "Home" page (though you'll be able to disable this check), with a separate "Updates" page for actually installing them.

In Reply To:
Also a list of auto-updated files should always be available, so if someone has made e.g. hardcoded mods, he/she gets to know, that his modified file was overwritten by a new update and is informed that he has to do the mod again.

We'll do that for individual file updates (i.e. Official Bug Fixes), but for a full release (e.g. Gossamer Links 3.0.1 from 3.0.0) it won't be available.

In Reply To:
The (LSQL/Forum) email/newsletter-functionallity should be developed:
A possibility of using eMail-attachments would be very nice.
Also some kind of newsletter/mail-bounce-handling would be very great!
At last the newsletter-subscription-functionallity should use an double-opt-in.

There are some e-mail enhancements due, but I don't think we'll be able to completely overhaul the newsletter e-mail handling, at least not for the initial 3.0 release.

In Reply To:
LSQL-Categories:
It would be very nice, if it'll be possible, if the admin could exclude categories from link-submitting.

It shouldn't be difficult to add; I'll add it to the list. Perhaps a three-way option: "Allow", "Deny", "Inherit", where "Inherit" is the default and pulls the value from the parent category. That said, I'll be creating a forum later today specifically devoted to new product features - I'd prefer to keep this thread more generalized to product-wide features.

In Reply To:
Cheers,
Manuel

Thanks for the feedback!


For the sake of clarity, the "GT Dev Team" user account consists of the core personnel Jason Rhinelander, Adrian Yee and Jack Ong. It was created so we could receive notification collectively.

Gossamer Threads Development Team
Quote Reply
Re: [nt6] Gossamer Threads Development Survey In reply to
In Reply To:
Flagging categories as visible or not, should be implemented in LSQL...

This shouldn't be difficult to do for v3. Would you want non-visible categories to still be accessible? That is, should an invisible category still be available - just not linked anywhere?

In Reply To:
What about existing plugins? Will they keep on working in the 2005 versions?

Yes, plugins and current (i.e. v2) templates will continue to work with v3 products. However, there may be some cases where we have to remove, replace, or change plugin hooks - if this happens, we'll clearly explain what has changed and what needs to be done for the new system.

Gossamer Threads Development Team
Quote Reply
Re: [GT Dev Team] Gossamer Threads Development Survey In reply to
It would be great to have categories that would still be accessible or not depending on their content.

Thank you for considerring this.
Quote Reply
Re: [wickedmoon] Gossamer Threads Development Survey In reply to
In Reply To:
CSS - I see this one as self-evident. It's a good idea.

That's pretty much our feeling - our main concern is whether it will pose difficulties for people who don't know much about HTML or CSS. Undoubtedly it will be more difficult for some people, but hopefully we'll have a system that looks better overall and in the end is easier to make significant changes to.

In Reply To:
What are the statistics for Internet users with or without javascript?

It's hard to say - I expect that 99.9% of browsers support Javascript, but the question remains as to how many are paranoid enough to turn Javascript off. There are, however, sites appearing now that absolutely and completely depend on Javascript - Google Mail being a recent, popular example.

In Reply To:
Formats for manuals - I'd say use all three, PDF, HTML and MS Word. I don't want to be presumptious, but I wouldn't have thought the overheads in time would have been that bad having to update all three.

It isn't, but if no one finds the PDF format useful (as opposed to a MS Word .doc, which is how we write it), we can simply distribute the .doc file instead.

In Reply To:
Personally, I rarely use PDF, preferring HTML for my online software. I only tend to use doc or txt files when I'm installing software on my home machine. A short txt file explaining the basics after I've unarced Gossamer Mail is sufficient for me, with the main documentation online.

This falls into the Tutorials I mentioned - the PDF vs. DOC vs. HTML applies just to the main product manuals, which are currently only distributed as PDF's.

In Reply To:
Installation - my feeling has been to wait for a while after a product is released. I would always read numerous bug reports in software updates. It always seemed a bug fix for the bug fix was released, so it made sense to wait before installing an update.

Hopefully Gossamer Update will solve this problem.

In Reply To:
Personally, I think designing the templates to work in popular and widely used software like Dreamweaver is a must. This is entirely possible, no matter how complex and convoluted the templates, as I do it myself with scripts that make dynamically created content.

I'm not certainly how we could go about making them Dreamweaver-safe - generally most gui editors seem to have problems handling something like:

<input type="radio" name="blah" value="1"<%if checked%> checked<%endif%>>

Some try to correct this (thereby breaking it), others don't display it properly at all.

Gossamer Threads Development Team
Quote Reply
Re: [GT Dev Team] Gossamer Threads Development Survey In reply to
In Reply To:
This falls into the Tutorials I mentioned - the PDF vs. DOC vs. HTML applies just to the main product manuals, which are currently only distributed as PDF's.[/quote]
Personally I would just like an online version of the docs on the GT website. It would be easy to find and easy to reference if helping people on the forum.
Quote Reply
Re: [DogTags] Gossamer Threads Development Survey In reply to
In Reply To:
CSS - the only thing that worries me is table elements.

CSS is great for font stuff, colors, and things like that, but for tables it's still pretty much cutting edge. I'm not sure if you intend to use css for tables, but I thought I'd throw this in.

We're actually aiming for a table-less design, except in cases where there actually is tabular data. Using tables for positioning is a bad practise in a strict XHTML+CSS design, and ends up constricting the design to a particular layout. Using div's (or other block elements) allows for greater flexibility in the design of the page. Most of the use of tables, currently, is specifically for layout, but nearly all of that can be accomplished with CSS.

As an example of how much can be done with CSS, I recommend you take a look at www.csszengarden.com - all the different designs on this page (there are well over a hundred, and it is growing all the time) use exactly the same HTML, except for the stylesheet included. Different stylesheets can completely change the look - from images, to positioning of elements (i.e. some have the "Choose a design" links on the right, some on the left, some oriented left-to-right above or below the other content), to possible omissions of certain parts of the data, to fonts and colours - this is what we are hoping will be possible with a proper XHTML/CSS design.

Gossamer Threads Development Team
Quote Reply
Re: [Chaz] Gossamer Threads Development Survey In reply to
In Reply To:
3) I've never liked using JavaScript in any of my applications but there are times when you just need to. I think as long as you can keep it out of core features like you mentioned it would work for me. I do like the added functionality in your example and I think I could learn to be more open minded about it. Are you noticing people turning of JS for security reasons at all?

Not really, though there have been a few complaints about javascript from time to time. I think the recent requirement and complete dependence on javascript by Google Mail does something towards validating javascript being enabled. Of course, we don't want to go so far as to say "No javascript = doesn't work" - but it is becoming more and more common on pages.

In Reply To:
4) I like PDF the best myself. I would, however, like to see the manual as HTML in the application as well. But what would that do to the download size of the app?

If it significantly affects the download size we would probably put it on our site, and just link to it from the download area.

In Reply To:
5) Not personally. But I think more info on file permissions and other common problems (images in the cgi-bin) would help alleviate some support time on your end though.

6) Yep, see #5. This would be a good area to cover a lot of your common support problems that can really be taken care of by the end user doing a little homework. A FAQ in addition to tutorials would be nice.

We'll most likely set up a Frequently Asked Questions section of the product pages that deals with these sorts of situations.

In Reply To:
7) With the Plug-in system (which I really enjoy) such a big part of your applications I would like to see better, more up to date, POD in your modules. I would also like to see a section on your website for the HTML versions of the POD. It would also be nice to see some of your core modules released on CPAN. I think GT::Template is just awesome but I can't use it as often as I would like :) And I just can't find anything close to GT::SQL.

We don't have any plan to do this at the current time. One of the problems is that doing so would put us under a certain amount of pressure to support our modules to people other than our clients.

In Reply To:
In lieu of releasing your GT::* modules to CPAN would you be open to some sort of a developers license?

This is something that we've discussed before and - if there is suitable interest - is something we are certainly willing to consider, but not until after the v3 release.

Gossamer Threads Development Team
Quote Reply
Re: [GT Dev Team] Gossamer Threads Development Survey In reply to
In Reply To:
We don't have any plan to do this at the current time. One of the problems is that doing so would put us under a certain amount of pressure to support our modules to people other than our clients.

I can certainly understand your point there. On the other hand, you would have the Perl community at large to help with that in the way of patches and tests. Just another way to look at it. Either way I do think the POD needs a bit of help in places. Don't get me wrong, I'm grateful for what's there, but I've found a few things missing or incomplete and/or outdated or incorrect.

In Reply To:
This is something that we've discussed before and - if there is suitable interest - is something we are certainly willing to consider, but not until after the v3 release.

I'd definitely be interested. I'll check back after the V3 dust settles.

Thanks,
Charlie
Quote Reply
Re: [GT Dev Team] Gossamer Threads Development Survey In reply to
In general, any change which makes services dependent on it more marketable (and aesthetics as perceived by the end user is definitely a part of it) is a welcome change. Even if that means tougher job on modification of templates etc it's welcome. My suggestions would however be:
  • Gossamer Community support Gossamer Applications across different domains (without removing the URL based sessions in Gossamer Mail as that would break wap support).
  • This has been touched earlier, but a centralized GT libs location with installer configured to handle the same accordingly during upogrades (for multiple GT Products license holders).
  • Auto-updates off GT Server as an _OPTION_ would be fine.
  • Documentation/Tutorials on GT server would be fine.
  • A KB/FAQ (Product Wise) drawn from This forum. I remeber modernbill building FAQ from their forum so that repeatedly same questions are not asked (and answered) over and over again.


Perhaps more when the product forums for 2005 version(s) are launched individually.

Also, if allowed to ask, when is the 2005 version(s) in 2005 expected to be released? If not too long, i would prefer to keep upgrades on hold for the time being.

Thanks
HyTC

Thanks
HyTC
==================================
Mail Me If Contacting Privately Is That Necessary.
==================================

Last edited by:

HyperTherm: Nov 15, 2004, 7:09 PM
Quote Reply
Re: [GT Dev Team] Gossamer Threads Development Survey In reply to

  1. What do you think of the XHTML+CSS design described in the announcement? Do you think this is a good or poor move, and do you have any suggestions, alternatives, or other ideas that we might consider?

  2. Yes, using CSS is a good idea, until there is NO CSS and HTML codes hardcoded into the GT app codes.
    GT should only use CSS as long the NS4+ and IE4+ compatibility is maintained!!! It should be kept backward compatible, and readable with 4.x browsers.
    Also be careful with using CSS in tables (+1 vote for worries of DogTags).


  3. How important is backwards compatibility with older browsers to you? When we say compatibility, we are talking about extremely old browser versions - that is, Netscape 4 and IE 4 - which already are incapable of displaying much of what is on the internet successfully.

  4. Very important to keep NS4.x, NS6.x , IE4.x, IE5.x, IE 6.x, Mozilla 1.x backward compatibility!
    Backward compatibility should be done to degrade design correctly, and still to keep readable all the texts.
    I see day by day such websites, which are working on IE, but when you look with your favourite browser, it is not viewable or doesn't display correctly. I don't want such problems, therefor my compatibility policy is to keep compatibility with 4.x browsers.


  5. Are you generally opposed to or in favour of using javascript to add functionality? Up to now, we've taken the policy of using javascript to augment existing capabilities or provide convenience features, with some notable exceptions such as the advanced editor in Gossamer Forum and Gossamer Mail. In the new versions however, we are planning some features that absolutely require javascript in order to work rather than to simply augment existing capabilities.
    ...
    Not having to support both javascript and non-javascript versions will free up time otherwise spent coding and maintaining both versions which will allow us to spend more of it working on new features for our programs. Additionally, it will keep the templates and the code cleaner without extra 'duplicate' code.

    I never liked to have javascript in a feature, because when javascript was turned off, the service was unusable.
    Imagine a link, button, menu, which is javascript based, and doesn't degrade correctly. It is a crap.
    If javascript is degraded well, so is kept working even if javascript is turned off, then yes, I support to have javascript used.
    My javascript policy is to use javascript for secondary features to add more interactivity for the service, and should degrade well, without destructing the design and readability.
    You can not avoid to support both javascript and non-javascript versions, because to degrade correctly you need both!



  6. What suggestions do you have, if any, for the product manuals? Do you find the current format (PDF) useful, or would you consider that we make the manual available in another format, such as MS Word (.doc) or perhaps even broken down into multiple HTML pages?
    PDF manuals are fine. But missing documentations should be created for developers guide, and modules POD. You know there are some modules, where there are a lot undocumented modules, like GT::SQL::Display::HTML , etc...
    HTML format would be not bad, since a HTML site can be converted finely into a PDF file.
    Additionally, a FAQ would be nice. (+1 vote for idea of Chaz)



  7. Have you had any problems with the installation of our products? How can we improve the installation process? Would an installation tutorial be useful?
    I had no problems. But automatic upgrades, bugfixes would be really fine. Just press "Check version" to check if there are any updates. Then "Update selected package" will install the selected updates. Note: that install order of different update packages may be important.



  8. We're considering adding a "tutorials" section to the product pages of our website to cover various common tasks associated with administering our products comprising items such as installation (question 5), a Getting Started Guide (e.g. for Gossamer Forum, how to create a Category and Forum), making simple template modifications, etc. Do you feel this addition would be useful, and if so, are there any specific areas in addition to the above that you would like to see?
    Yes, tutorials section would be useful. That would make easier to start new GT users installing, customizing, improving GT applications.



  9. Are there any specific weak spots in our programs currently that you would like to see addressed, with respect to how the overall programs work? We do not refer here to individual product feature requests for this question - but rather areas that affect all of our programs, such as installing, modifying templates, upgrading, etc.
    Yes. There are some long waited features listed here:

    • !!! Common API level above GT apps - currently there is no common application API between GT apps (I mean not the GT lib, but the application library, like Links, Comm, etc...).

    • GT application cross-access integration - a new module (with an easy API) into GT module collection, to be able to cross-access all GT application tables, main config files, plugin config files, hooks, modules, plugins.
      The Module could be named GT::Integrate or GT::Apps, with submodules, like GT::Integrate::LinksSQL, GT::Integrate::GForum, etc...

    • !!! Admin login separate script - Admin login should be moved to a separate script, which can be renamed for security reasons

    • !!! Support multiple language in same template set!!! (without the need to open new template for each language)

    • !!! Support to 1 common GT module directory for all apps

    • !!! Support to 1 common template module directory for all GT apps

    • !!! Support dynamic_preserve feature in all GT apps

    • !!! Support for caching of output html feature (small timeframe and same input variable content)

    • !!! URL generating - Support to make URL parameter names changeable. Currently URL parameter names are hardcoded in GT apps!!!

    • !!! Template parsing of ConfigData.pm values! - Support to make possible to use a config variable within another config variable!!! Example: $CFG->{"server_URL"} = "http://www.site.com"; $CFG->{"db_cgi_url"} = "<%$CFG::server_URL%>/cgi-bin/Lsql";

    • !!! Support LSQL a section based template system, with reusable, changeable sections, inheritable into subcategories. This means to inherit template elements, sections, local & global variables into subcategories - This would be excellent GT template feature improvement. Currently only one full template can be inherited and overrided in the subcategories (Category_Template). But if I want to change the design, I need to change all templates, depending which part of template is changed. I have to include even <head> or <html> tags redundantly, when these should be used once when design is done, then should be automatically reused where needed. Therefore the main category page should provide a skeleton (section) of the design, then subskeletons (subsections) recursively, which should be inherited to subcategories. I will open a new thread for this later, then will explain how this section based template system should work in LSQL.

    • ! Support WAP/WML? - Support WAP/WML in all GT apps

    • ! Support FastCGI - long waited feature, which would make possible additional crossOS permanent environment beside mod_perl. SpeedyCGI is not crossOS solution, available on Linux only.

    • Support LSQL to have virtual category links to other category (shortcut) - So you can create an Electronics/Computers/Accessories category, which is "virtually linked" to Computers/Accessories. So opening page Electronics/Computers/Accessories will display same links like in Computers/Accessories, but with different template design if needed.

    • Support LSQL to hide categories (+1 vote for idea of nt6)

    • Support LSQL to set to exclude categories from link-submitting (+1 vote for idea of ManuGermany)

    • Support to handle mail-bounce-handling (+1 vote for idea of ManuGermany)

    • Support to have the GT plugin developers able to check if they are currently on admin interface, or on public user interface. There is MISSING a global variable, which is set if we are printing to admin interface or to public page.

    • CPAN release of at least GT::Template module. CPAN release of full GT lib would be also a good idea, but since you may have some business interests not releasing publicly, I can just mention that this would be fine.
      But think about, that this would greately advertise the www.gossamer-threads.com website and products...
      And since the products are really fine, that would mean a lot more buyers. (+1 vote for idea of Chaz)


Waiting GT staff comments!

Best regards,
Webmaster33


Paid Support
from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Quote Reply
Re: [GT Dev Team] Gossamer Threads Development Survey In reply to
First of all, the automated patching should be able to be disabled on every level. I am not a fan of automated patching and would no use it.

Checking for updates is also a touchy one. I personally don't care but several of my clients only agreed to purchasing GT products when assured there was no "phoning home" for privacy reasons/paranoia.


Quote:
What do you think of the XHTML+CSS design described in the announcement? Do you think this is a good or poor move, and do you have any suggestions, alternatives, or other ideas that we might consider?


I personally don't care as I don't (and won't) use any default templates.

But if this means a bunch of CSS will then be controlled by the software I wouldn't like that. Me, I like the amazing template syntax and I'll handle the markup and style from there.

Quote:

How important is backwards compatibility with older browsers to you? When we say compatibility, we are talking about extremely old browser versions - that is, Netscape 4 and IE 4 - which already are incapable of displaying much of what is on the internet successfully.


Ideally designs can degrade gracefully. For example, I have some bleeding edge CSS designs that can still be viewed on old browsers, they just look plain (like professor's pages, with header tags and text) and all a logical order.

But either way, I'm fine with CSS.

Quote:

Are you generally opposed to or in favour of using javascript to add functionality? Up to now, we've taken the policy of using javascript to augment existing capabilities or provide convenience features, with some notable exceptions such as the advanced editor in Gossamer Forum and Gossamer Mail. In the new versions however, we are planning some features that absolutely require javascript in order to work rather than to simply augment existing capabilities.


Depends on the features. I keep JavaScript to a minumum, and hope that such useability and compatibility principles will be taken into consideration. Any browser specific code would be a bane, IMO.

Quote:
What suggestions do you have, if any, for the product manuals? Do you find the current format (PDF) useful, or would you consider that we make the manual available in another format, such as MS Word (.doc) or perhaps even broken down into multiple HTML pages?


I prefer multiple html pages. But this is a very low priority for me.

Quote:
Are there any specific weak spots in our programs currently that you would like to see addressed, with respect to how the overall programs work? We do not refer here to individual product feature requests for this question - but rather areas that affect all of our programs, such as installing, modifying templates, upgrading, etc


Scalability. Gossamer does pretty well, but what's preventing me from using the product on some of my sites is lacking scalability (e.g. distributed files over multiple servers).

Data integrity. The file uploads, settings and database could really use a powerful backup/restore function with incremental and remote backups.

I'll also note that the license changes are unwelcome here, I chose Links SQL for the basis of my development with many clients, and would prefer a higher price to a limited license.

Or maybe one benefit of people who send a lot of business your way with multiple liscenses and many referrals would be lifetime licenses.

cdkrg

Able2Know :: Ajooja Directory
Quote Reply
Re: [GT Dev Team] Gossamer Threads Development Survey In reply to
One for LSQL:

Allow users to edit their information, as well as request a new validation key (of they missed the email).

cdkrg

Able2Know :: Ajooja Directory
Quote Reply
Re: [GT Dev Team] Gossamer Threads Development Survey In reply to
In Reply To:
I'm not certainly how we could go about making them Dreamweaver-safe - generally most gui editors seem to have problems handling something like:

<input type="radio" name="blah" value="1"<%if checked%> checked<%endif%>>

Some try to correct this (thereby breaking it), others don't display it properly at all.

Because of the markup and the nature of piecing together separate templates, you'll always get invalid tags in a HTML editor. Firstly, at least in Dreamweaver, you can turn rewriting off, so code doesn't break. Secondly, I don't believe a few tags reported as invalid is an issue. The problem is the essential structure of the templates. I would often load a template into Dreamweaver and nothing much at all would display. Tables were sometimes invisible. I think most of these structural issues could be resolved if some consideration were given to widely used HTML editors like DW. My copy of GMail is still described on your site as being extensively modified, but I gave up doing that because the templates were so frustrating to work with. I was forced to edit the HTML by hand, which I am very experienced with, but I found creating the design effects I wanted next to impossible, and took to making very basic alterations instead.

Like I say, I have worked with scripts that create dynamic content. The biggest project was ecard software I designed that was pieced together in the same way as Gossamer products, ie custom tags and hundreds of templates pieced together for the final output. Displaying a template was never a problem and I used Dreamweaver exclusively. Even tables that begin in one template and end in another are not really a problem. I was able to visualise and edit template layouts in the same way as I would see them online, in the finished product. In this way it was easy to rip apart everything and redesign from scratch, to concentrate on the important aspects of graphic design, colour combinations etc, rather than being distracted by and limited to using hand coded HTML.

Jason
Quote Reply
Re: [GT Dev Team] Gossamer Threads Development Survey In reply to
The zengarden example is as you say in an impressive set of examples of what can be done with CSS, but I agree with DogTags and webmaster33 that CSS is not quite capable yet of covering various table type layouts and also forms and not too easy to manage when they get long. I've also found that dynamically generated content when the text varies in length and these items are placed one after each other which means different hights are pretty tricky to deal with.

This said CSS is not presently an end all solution. At the moment I feel it is a transitional phase since it provides a great amount of power for web page design but not all browsers are compatible and often tweaks are required even between compatible browsers. If the question is "Is it worth investing in CSS?" I personally am. With the venue of FireFox I think Microsoft will be less inclined to reject the W3C's standards. Not that FireFox is sure to win any battles but I think it will have an impact and Microsoft's image as a monopoly on the web browser front which is not good even for Microsoft.

This leads to the compatibility issue. Having worked on large web sites in Europe for several years I personally get really mad about having to design web pages in such a way that certain key functions are dropped because of old browsers. That said I understand the situation, do you want to push away potential clients if we're talking about a business. My usage is not for profit, not a business and so I don't really want to think about spending an extra month or more of my time for a very small percentage of my target population and reduce functionality for everyone else in the process.
I do agree however with the stance that says producing flash navigation with christmas bells etc. for the sake of being "flash" (excuse me for the pun) is a bit over the top for me. When multimedia type content is provided for demos, training etc I see the gain but having the page moving all over the place to please the designer just seems excessive.

Javascript, sorry not really thought about it but the comments posted above seem interesting and the GoogleMail reference seems to back the move from my point of view. BTW What is the difference between ActiveX and Javascript (a bit blurred in my mind) the first always seems to be coming up in security discussions I have at work and being far more dangerous than Java.

Product manuals. I think that an html version would be good and a pdf version I don't see the need for a word version.

I think that an installation tutorial would be a good idea, especially for new users even if you are talking about automatic updates. Permission to speak freely ? I can understand working in the computer consultant industry that it is interesting to have clients refer to the editor to install the software but making it easy to install will open new doors and let you provide other services and/or functionality and many who would have asked for the editor to install will most probably do so anyway.

I think that providing a guide to explain how you can change things, which version it applies to and what level you need to be to do it etc. would be a tremendous plus for everyone. I think that just like Laura says above that being able to refer people to hands on areas that explain in clear and simple english what they need to do would be great. The only issue I see would be making sure that the tutorials indicate for example if the modifications only work with version X.X and not with Oracle but will run under mod_perl etc.

Just out of curiosity have you ever thought about creating a workgroup system that would enable programmers to work together on specific tasks and/or a points system that would reward people that provide feedback to other users that they feel has provided them with the solution they were looking for ?

I would really, really, really like to see the editors in LinksSQL being able to manage more in the validation process...
The one are that I feel is not that easy to manage is the templates that are used on LinksSQL to create links, the way they are ordered and displayed.
Oh and what type of security checks will be incorporated to ensure that hackers can't use the automatic updates system to attack the server ?
Significant Media
Quote Reply
Re: [GT Dev Team] Gossamer Threads Development Survey In reply to
As it has been mentioned several times, we want to stress that the Gossamer Update feature will not automatically update your installation. It will provide an easy way to see what updates/fixes are available your installation, and allow you to select them to be installed.

Gossamer Threads Development Team
Quote Reply
Re: [cdkrg] Gossamer Threads Development Survey In reply to
To provide more information on your issues regarding scalability, we just wanted to point out that we do have some sites running our programs in a clustered environment. For a couple of examples, please check out our new Clustered hosting page here:

http://gossamer-threads.com/hosting/clustered.html

As for the licensing issues, please do feel free to contact Jack directly about that and he can work out details with you that suit your particular needs better.

Thanks for your support of Gossamer Threads and our efforts to continuously improve our offerings.

Gossamer Threads Development Team

Last edited by:

GT Dev Team: Nov 16, 2004, 1:12 PM
Quote Reply
Re: [GT Dev Team] Gossamer Threads Development Survey In reply to
In Reply To:
What this means is that if you have a Links SQL version 1 or 2 license, you will still be entitled to free upgrades for life. But if you purchase a copy of Gossamer Links v3, you will need to pay to upgrade to version 4.

What does this mean? I have version 2 of LinksSQL. I need to pay for version 3 or for version 4 when it comes out?


Let's talk about an important issue: timetable. I do hope that the GT Dev Team is now capable to set deadlines for releasing their products so customers can plan their works.
I don't expect you've already set a day for the release of each product but at least a month of 2005?
Thanks
Max
The one with Mac OS X Server 10.4 :)
Quote Reply
Re: [maxpico] Gossamer Threads Development Survey In reply to
Quote:
What does this mean? I have version 2 of LinksSQL. I need to pay for version 3 or for version 4 when it comes out?

I don't think it means this. Basically, existing customers will get FREE upgrades (v2.x => v3 => v4) .... but new customers will not get this benefit, so if they buy "Gossamer Links v3", and then when version 4 comes out; they would need to pay the upgrade fee. This is just my interpretation though :)

Quote:
Let's talk about an important issue: timetable. I do hope that the GT Dev Team is now capable to set deadlines for releasing their products so customers can plan their works.
I don't expect you've already set a day for the release of each product but at least a month of 2005?

Its very easy coming from a client's point of view... but timetables are almost IMPOSSIBLE to keep to (unless you happen to have a huge development team).

I know for a fact that GT work their hardest to get products out on time ... but they are still humans... and not everything goes to plan when writing software :| (especially stuff that is as complicated as GT's products :p).

Just keep that in mind Angelic

Cheers

Andy (mod)
andy@ultranerds.co.uk
Want to give me something back for my help? Please see my Amazon Wish List
GLinks ULTRA Package | GLinks ULTRA Package PRO
Links SQL Plugins | Website Design and SEO | UltraNerds | ULTRAGLobals Plugin | Pre-Made Template Sets | FREE GLinks Plugins!
Quote Reply
Re: [Andy] Gossamer Threads Development Survey In reply to
In Reply To:
Basically, existing customers will get FREE upgrades (v2.x => v3 => v4) .... but new customers will not get this benefit, so if they buy "Gossamer Links v3", and then when version 4 comes out; they would need to pay the upgrade fee. This is just my interpretation though :)
Let's hope is that way ;)


In Reply To:
Its very easy coming from a client's point of view... but timetables are almost IMPOSSIBLE to keep to (unless you happen to have a huge development team).

I know for a fact that GT work their hardest to get products out on time ... but they are still humans... and not everything goes to plan when writing software :| (especially stuff that is as complicated as GT's products :p).

Just keep that in mind Angelic

It's useless that everytime one criticizes GT for their unmet timelines you reply with this same stuff. Nowadays in this fast paced world if you're not able to meet timelines you'd better change job or at least you're not successful. It could happen two, three times not to meet an already announced timeline and even so not with several months of delay.
I'm not saying this is easy but you really cannot say that "timetables are almost IMPOSSIBE to keep to...because we're humans". Sorry but this is a loser attitude Tongue
Max
The one with Mac OS X Server 10.4 :)
> >