Closed (fixed)
Project:
Answers
Version:
7.x-3.x-dev
Component:
Miscellaneous
Priority:
Major
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
15 Dec 2012 at 18:19 UTC
Updated:
20 Feb 2013 at 00:47 UTC
After testing answers I decided that I didn't feet my needs due to usability concerns. I wanted a closer version of StackOverflow's system. Thats why I created a module that, even having the same functionality, differs in usability and architecture: http://drupal.org/sandbox/ALMADEWEB/1757352
You ca see a demo here: http://qas-demo.almadeweb.es/
Following the ethos: collaboration rather than competition I propose joining with answers.
Diferences of qas with answers (I believe those are all advantages of qas):
I think that qas will be easier to maintain than answers (points fron 1 to 6) and easier to use (points from 6 to 8).
I leave it here for your consideration.
Cheers
Alessandro.
Comments
Comment #1
luksakThank you for posting this. I kinda had the same feelings when I started my Q&A stackoverflow.com cloned site development three weeks ago. I also customized answers a lot (did you actually use it as a base?). But I've chosen a different approach. I did most of the things using site building. I created my own views and used panels to display them. I also created a few notifications using http://drupal.org/project/notifications. My main concerns are not using entityreference and flag. This automatically brings a lot of flexibility to the module. And I also agree with most of the other things on your list. But I think we should start to use the proper data structure. So the fist thing would be to migrate to entityreference. I already created a issue for that: #1858350: Migration to entityreference
The other part is that you did code most of the functionality. For some thing it makes sense. For others it doesn't. I don't understand why answers is sending emails out in code. This should be implemented with rules. As I said, notifications is the perfect tool for this. Let's use it!
Another bad example of hardcoded functionality is displaying the login form when visiting node/add/question as an unauthorized user.
Also we need to make sure that it all integrates with panels an views.
Another topic would be if you intend to publish your sandbox as a project. Since answers has 400 D7 installs, I would suggest to implement the improved design patterns from QAS to answers. What do you think?
We should create a meta issue or just use this one to track all different issues.
Looking forward to hear from you guys!
Comment #2
AlessMascherpa commentedHi Lukas,
Is nice to see there is people with interest :)
QAS doesn't use answers as base. It is inspired by it though. QAS is written from the ground up. Is based in Content types so you can modify questions and answers with Field UI. Also based on views, so you can modify views or integrate them with panels, OG, or other modules from Drupal ecosystem.
My first choice, will be to merge QAS into answers, as you mentioned, rather than upgrading QAS to full-project. QAS and Answers have the same goals. Therefore last decision is @chipcleary's, the answers maintainer, though.
I feel that QAS/Answers should be as basic as possible. Notifications is a great module but also complex. I feel that this configuration can be done in complementary modules/features.
Regarding your comments about sending mails and redirecting users to login pages in a hard-coded way, I imagine that you are talking about Answers. QAS does nothing of this. You can configure this behavior with rules and permissions.
Cheers,
Alessandro.
Comment #3
chipcleary commentedBTW, as a heads up, I believe merging is a good path. I have installed QAS, done an initial review of the code, and done an initial review of the interface.
In sum, I agree with Alessandro's assessment in #1 above. QAS is a cleaner implementation. The improvements in the UI are important. This is even a particularly good time to make a shift since we need to make a change in architecture in the D7 version in any case due to entityreference, as Luk raised in his issue.
I would like to spend some more time over the next week to consider the differences in functionality. Answers does provide for some features that QAS does not. I'd like to map out what those are and collaborate to identify what path(s) we might take on them moving forward. The discussion above about hardcoded vs. Rules vs. Notifications is an example.
(As a side note, I also agreed with Alessandro's point above, the "bad hardcoding" Luk mentions is part of the current implementation of Answers, not QAS.)
Comment #4
luksakYes, I was talking about answers when I mentioned the hardcoded stuff.
@chipcleary: Exactly, do a review of the differences between the modules. Then we should define the goals we want to accomplish and create a roadmap.
You are right, we should keep functionality such as notifications in contrib modules. We should review functionality in answers core and think about moving it to separate modules.
Comment #5
AlessMascherpa commentedThank you @chipcleary for the interest and nice words about QAS. Is always nice to have good opinions about your work. Reviews, either good or bad, are always welcome. Part of my interes in joining QAS with Answers is improving the module.
Yes @Lukas, we have to define the module goals and create a roadmap. Before we can do that, we have to figure out, decide and organize, how to merge both projects, and list the main diferences between them. After that we can decide what goes in Answers and what goes in Answer sub-modules or external modules/projects.
One main difference between QAS and Answers, is that QAS is not based in Features. It has to be hand coded. Exportable configuration of Views, Rules, etc, helps a lot, though. Features is great but I don't know if it can offer the flexibility needed to build QAS and to keep things separated in different modules. As I see it, the options for merging are two:
Either way, Features can still be used in adding especial case functionality and configuration, especially in external modules. As QAS, like the three main Answers modules, is based in nodes, views, rules, flag, rate/votingAPI and user points, I think that many of the existing Answers modules will need little adjustment to be adapted to QAS If we walk the first path, and maybe none if we take the second one.
Things that would require more effort will be:
- Migrating from previous versions to the new one
- Drupal 8 version. I have no clue, but think that exportables, features an configuration management have improved a lot in D8.
Cheers
Alessandro.
Comment #6
migs13 commentedsubscribing
Comment #7
luksak@chipcleary: Could you make a proposition how to proceed on this?
As a site builder I like working with features. Even though not a lot modules providing similar set of tools (views, content types, etc.) have a dependency on features. So maybe we should try to drop it? I can't really judge this one...
Let's keep this conversation going.
Comment #8
chipcleary commentedHi all, just a quick update after some time.
I do plan to proceed with this ... and expect to start shortly. My basic plan is:
Help very welcome with this shift. I understand from Alessandro that he will not be spending time with Drupal in the near future ... so cannot pitch in. Would you be interested in taking on part of this ? In particular, I'd love help on the data transfer approach (#4 and 5).
Comment #9
luksakGreat to hear this. looking forward to see this! Let me know if you need any feedback.
Comment #10
ivan zugec commentedI can help out. I just played around with QAS and it looks pretty good and I think it's a good direction for Answers.
@chipcleary, What do you need help with? It looks like you need help with version upgrades (fun, fun) :). That is something I can look at.
In the mean time, should I create an "upgrade" issue?
Comment #11
chipcleary commentedHi all, I very much appreciate the offers of help.
Here's how I suggest we tackle this. I have now created a version 7.x-4.x of Answers. This simply takes the work that @AlessMascherpa did on QAS and port it directly. Very few and minor changes to that code.
So, we're started.
Next, I will create feature requests for the work items to be done. If you are interested in pitching in, please either:
I'd particularly appreciate help on the import-export feature so that people can migrate to the new branch.
How's that sound? If it's reasonable, we can close this issue and start work on the features.
Comment #12
chipcleary commentedI'm closing this as an "open issue" since the work is underway. All who would like to contribute can do so by making feature requests or implementing feature requests for 7.x-4.x-dev.