Hi Joe, Thank you very much for your valuable feedback and offering me help and guidance in the implementation stage. And it really increases my confidence.
>> Yes, this should even be possible using plain CSS. If you position the >> button absolutely within the <ul> element to the top right for example, you >> can then set it to display: block; on ul:hover, display: none; otherwise. Thanks for the snippet Joe ;) I'll use this for sure. (Just to be clear, I didn't mean we MUST use AJAX. In my opinion the technology doesn't matter. AJAX,JAVA SCRIPT, CSS or whatever, please help me just to identify the best way to get the best out come.) >> One way to do this would be to let users create a 'ticket table' with a >> simple macro: each row would be a new ticket, each column one required >> field. Once they are filled in and the user clicks save on the wiki page, >> all rows would be converted into tickets. Again thank you very much for the idea Joe. This will be a really good solution, and somehow it never did come to my mind. I have attached another mockup at [1]. Please take a look and let me know whether is that what you have meant :) [1] https://issues.apache.org/bloodhound/attachment/ticket/231/design_mockup_v2.png On Fri, Mar 7, 2014 at 9:59 PM, Joachim Dreimann < [email protected]> wrote: > On 6 March 2014 15:42, Dammina Sahabandu <[email protected]> wrote: > > > Hi Gary, > > First of all thank you very much for the quick reply. > > > > > Hi Dammina, > > > I'll go through this in more detail later but I notice that the > > > attachments that your refer to are not available. > > > > I know you got a really busy schedule. And of cause I'm not in a hurry. > So > > no worries, please take any amount of time to reply :) (And I'm really > > sorry if I'm disturbing you with these minor issues). However, I did > attach > > that mockup snap into the location that you suggested. You can find it at > > [1]. > > > > [1] > https://issues.apache.org/bloodhound/attachment/ticket/231/mockup.png > > > > Thanks > > Dammina > > > > > > On Thu, Mar 6, 2014 at 5:20 PM, Gary Martin <[email protected] > > >wrote: > > > > > Hi Dammina, > > > > > > I'll go through this in more detail later but I notice that the > > > attachments that your refer to are not available. I suspect our list > just > > > doesn't allow them to be added. That leaves a question of the best > place > > to > > > put them. Attaching them to https://issues.apache.org/ > > > bloodhound/ticket/231 might be appropriate for now I suppose. > > > > > > Cheers, > > > Gary > > > > > > > > > > > > On 06/03/14 11:38, Dammina Sahabandu wrote: > > > > > >> Hi Gary, > > >> > > >> Thank you very much for the quick detailed feedback. It really helps > me > > >> and motivates me a lot. Here I have briefly described few design > > decisions > > >> on how to solve the issues that we have discovered already. > > >> > > >> Regarding List tracking in a wiki page: > > >> A regex pattern matching search for '*' , '1.' etc. markups in the > > >> complete content on the wiki page will be able to find all the > numbered > > >> lists and bullet pointed lists. But still I have to face the problem > of > > >> Intrusiveness. So I'm thinking of several ways to solve this issue. > May > > be > > >> setting up a hidden comment(It should be some universal identifier. > For > > an > > >> example > > >> {{{#!comment > > >> TicketList > > >> }}} > > >> ) in the wikitext to identify only the relevant lists will be a good > > >> solution. I guess it won't be a considerable overhead for the user. Or > > may > > >> be we can just implement an AJAX script for the buttons visibility. > > That is > > >> the 'Create Tickets' button for a particular list will only be visible > > for > > >> the user when he is pointing the mouse pointer over that particular > > list. > > >> So by that way the user will only see one button at a time (Hope it > > won't > > >> be a big headache ;) ). So what is your opinion, will something like > > this > > >> work? > > > > Yes, this should even be possible using plain CSS. If you position the > button absolutely within the <ul> element to the top right for example, you > can then set it to display: block; on ul:hover, display: none; otherwise. > > I'm happy to help you with these sorts of things when you get to the > implementation stage. > > > > Anyway I will do some more thinking and try to figure out a better > > >> alternative. > > >> > > >> Missing details in auto created ticket: > > >> As you have mentioned, for this issue there are lots of solutions > > >> available. Currently I'm thinking of the following solution, and I > have > > >> attached few mockups to describe the it. > > >> 1. [mockup01] displays the initial view of the wiki when mouse pointer > > is > > >> not over a relevant list. > > >> 2. When mouse pointer is over a relevant list, the button 'Create > > >> Tickets' will be visible. [mockup02] > > >> 3. After the user clicks on the button the creating process will run > and > > >> display the links to appropriate tickets. And when the user pointed > the > > >> mouse over a certain ticket a button to update details of that ticket > > will > > >> appear.[mockup03] > > > > The bit about update details for a ticket seems inconsistent with how users > can normally interact with ticket links they encounter elsewhere. I think > it's ok if the user just clicks the link to go to the ticket page, with no > extra button appearing here. > > > > >> 4. Then if the user click on the button, there are two thing we can > do. > > >> i. Simply redirects the user to update ticket details pages. > > [mockup06] > > >> ii. Or generate a button list of required fields [mockup04] . > (Assume > > >> the state of the ticket will be 'new' and the reporter should be the > > user > > >> who add these list of tickets) > > > > I think we can set sensible defaults for all required fields. > > > > >> 5. If we choose the process (4. ii.), then the user can add details > in > > to > > >> the fields one by one. [mockup05] > > > > To edit multiple tickets, we should provide a link to an appropriately > scoped custom query that shows the tickets just created. We should try to > avoid introducing a separate way to do the same thing. > > >> > > >> Hopefully all these user side changes can be achieved by few AJAX > > scripts. > > >> > > >> Another easier way to solve this is to define a standard way to write > > >> these ticket lists in wiki pages. So we just have to process the list > > and > > >> extract the data appropriately. (Please let me know if this seams > > >> interesting to you. Then we can discuss this in detail.) > > > > One way to do this would be to let users create a 'ticket table' with a > simple macro: each row would be a new ticket, each column one required > field. Once they are filled in and the user clicks save on the wiki page, > all rows would be converted into tickets. > > > > >> Another thing is I'm not really clear about the idea of handling > > >> permission to add tickets using this feature. I mean as you suggested > > in an > > >> earlier message we need to think about, to whom we should provide > > >> permission to use this functionality. Initially, I was thinking that > > >> whoever has the permission to add tickets in the usual way should be > > able > > >> to use this functionality. But I'm not really sure about that. So > there > > I > > >> need a little help from you to make it clear. > > > > Yes, your suggestion seems sensible. > > Cheers, > Joe > > >> > > >> So what are your opinions on my suggestions. Obviously these designs > > need > > >> to improve a lot and for that the feedback from the community is > really > > >> important. > > >> > > >> Another thing is at the moment I'm trying to come up with some more > > >> suggestions on expanding the functionality of this feature. So if you > > have > > >> anything in your mind please let me know :) > > >> > > >> Thanks > > >> Dammina > > >> > > >> > > >> On Tue, Mar 4, 2014 at 10:46 PM, Gary Martin < > [email protected] > > <mailto: > > >> [email protected]>> wrote: > > >> > > >> Hi Dammina, > > >> > > >> Firstly I should point out that this project would ultimately be > > >> defined by you and so it is of particular importance that you make > > >> this both challenging enough and realistic enough for you to > > >> achieve in the available time. > > >> > > >> You have spotted a very interesting issue that you might want to > > >> solve as part of this project and if I were you I would certainly > > >> use this to strengthen your application. The ability for users to > > >> specify details like ticket type, milestone, components and other > > >> fields certainly seems very desirable to me but there are going to > > >> be various solutions to the problem which will vary in complexity > > >> of implementation and actual usability. > > >> > > >> If you come up with some suggestions, we could discuss what the > > >> community would prefer (and there is a good chance that we will > > >> make more suggestions if we can) but remember to continue to > > >> balance our advice with what you think is achievable. You may of > > >> course need our help to understand what may be easy or difficult. > > >> > > >> Anyway, it is great to see that you are spotting issues that might > > >> be solved. > > >> > > >> Another area you might want to give a little consideration to is > > >> whether there might be anything you could take advantage of from > > >> the context that the list is found in. In case you have not noted, > > >> wiki syntax is available in a number of places including wiki > > >> pages, ticket descriptions and comments. > > >> > > >> I hope that answered your question well enough! > > >> > > >> Cheers, > > >> Gary > > >> > > >> > > >> On 04/03/14 12:02, Dammina Sahabandu wrote: > > >> > > >> Hi Gary, > > >> Another thing that I wanted to clarify is, by this method we > > >> will only be > > >> able to add summaries for the created tickets. May be it will > > >> be possible > > >> to fetch the reporter information too. But there are many more > > >> important > > >> fields in a ticket that should be filled such as type and > > >> priority. So do > > >> we need to address this issue? > > >> > > >> Thanks, > > >> Dammina > > >> > > >> > > >> On Tue, Mar 4, 2014 at 4:03 PM, Gary Martin > > >> <[email protected] <mailto:[email protected] > > >> >>wrote: > > >> > > >> > > >> On 04/03/14 04:32, Dammina Sahabandu wrote: > > >> > > >> Hi All, > > >> > > >> I'm Dammina Sahabandu, a 3rd year Computer Engineering > > >> Undergraduate at > > >> University of Moratuwa, Sri Lanka. Currently I'm doing > > >> an internship at > > >> WSO2 inc which is an open source middleware > > >> organization. So I do have > > >> experience in several Apache projects (Axis2, Synapse > > >> etc.). So as the > > >> first step I did some background research about the > > >> Apache Bloodhound > > >> project. And also I did checkout the svn repo and > > >> installed > > >> it successfully. > > >> After going through the JIRA list I found several > > >> interesting ideas, but > > >> I'm particularly interested in the idea of creating > > >> tickets using a > > >> wiki list [1]. So as I understood simply the idea is > > >> to provide a button > > >> when there is a list in the wiki(numbered or bullet > > >> pointed). And we need > > >> to implement a system to create tickets using the list > > >> after the user > > >> clicking on that button. Then we need to update the > > >> wiki page(the > > >> > > >> relevant > > >> > > >> list) replacing the list with the links to the created > > >> tickets. > > >> Is that correct? Can you please give me a feedback to > > >> clear up the idea. > > >> And it would be really great if you can provide some > > >> more details about > > >> > > >> the > > >> > > >> project. > > >> > > >> [1] > > >> > > https://issues.apache.org/jira/browse/COMDEV-110?filter= > > >> 12326260 > > >> > > >> Thanks > > >> Dammina > > >> > > >> Hi Dammina, > > >> > > >> Great to hear from you. For quick reference here, the > > >> associated ticket > > >> for bloodhound is > > >> https://issues.apache.org/bloodhound/ticket/231 > > >> > > >> I believe your interpretation of the ticket is reasonable. > > >> What has been > > >> stated so far is probably not a full specification for the > > >> problem so it > > >> would be worth considering: > > >> > > >> * Permissions - who is appropriate for the button to be > > >> presented to > > >> and who can use the button? > > >> * Intrusiveness - not all lists will need to be turned > > >> into tickets so > > >> could there be means to determine this? > > >> > > >> That is a shorter list than I thought I would come out > > >> with but feel > > >> free to add to this, Dammina. As this would be your > > >> project, it might be > > >> better if you try to answer those questions rather than > > >> getting us to > > >> prescribe answers. This may be useful for strengthening > > >> your final > > >> project proposal too. > > >> > > >> Cheers, > > >> Gary > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> -- > > >> Dammina Sahabandu. > > >> Undergraduate Department of Computer Science and Engineering > > >> University of Moratuwa > > >> Sri Lanka. > > >> > > > > > > > > > > > > -- > > Dammina Sahabandu. > > Undergraduate Department of Computer Science and Engineering > > University of Moratuwa > > Sri Lanka. > > > > > > -- > Joachim Dreimann | *User Experience Manager* > > WANdisco // *Non-Stop Data* > > e. [email protected] > twitter @jdreimann <https://twitter.com/jdreimann> > -- Dammina Sahabandu. Undergraduate Department of Computer Science and Engineering University of Moratuwa Sri Lanka.
