Hi folks, First of all I wish to congratulatulate Alex about the past realease of 1.x version. We at the Univ of Helsinki, Finland found your software few weeks ago and there has been high interest towards your project. Our current qualitative research and research training relies heavily on Atlas.ti. It would be ideal to use such a software in bachelor and masters courses, since the students could use the software in their own off-campus computers. We have already made some initial try-outs with Weft and it look very promising! I personally found the Code Review feature very interesting, since I utilised similar techique in my own thesis few years ago. The monograph is available on the net (http://ethesis.helsinki.fi/julkaisut/kas/opett/vk/lattu/), for "category networking" see pp. 137-138 and one example of a network on p. 141. I''m very pleased to see that someone has come out with similar solution and made the implemention in a more user-friendly way than my own set of Perl-scripts... Then about the Magnus''s suggestion about viewing the already coded sections in the text view. I think this is the main drawback of the 1.0 version. Atlas.ti does a good job in visualising the codes in the right margin (c.f. http://www.atlasti.com/shot_hueditor.html). r. Matti L -- Matti Lattu Head of ICT Affairs Univ of Helsinki, Faculty of Behavoural Sciences matti.lattu at helsinki.fi +358-9-191 29738
Hi Matti Lattu wrote:> We have already made some initial try-outs with > Weft and it look very promising! >Thanks for your kind words. A few institutions here in the UK are also trying out Weft QDA for methods teaching. I don''t do any teaching myself, just research, so I''m interested to hear how it goes - what students find easy and heard, how the manual could be improved.> I personally found the Code Review feature very interesting, since I > utilised similar techique in my own thesis few years ago.Thanks for the reference. I have only very briefly tried Atlas, but what I gathered was that it supports more sophisticated ways of representing types and directions of theoretical relationships (causality, priority etc) between categories than Weft. In designing Weft I''ve tended to think of it as a "data tool" more than a "theory builder software". The range of possible knowledge objects, such as theories (of all sorts), hypotheses, models etc that can be generated in social science research is very large and very variable across disciplines and traditions - and individuals. So a software that can represent all these different types of objects is going to be hard to design, and likely complicated to use. On the other hand, I think the kind of judgements we make about data, such as similarity and difference in order to reach all our different knowledge objects vary less. So Weft tries to let you generate, record and develop your insights about data - but perhaps expects you to do more work - in other software, or, god forbid, even on a piece of paper - to describe models and theories.> Then about the Magnus''s suggestion about viewing the already coded > sections in the text view. I think this is the main drawback of the 1.0 > version. Atlas.ti does a good job in visualising the codes in the right > margin (c.f. http://www.atlasti.com/shot_hueditor.html). >I agree with you and Magnus that the text viewer is much weaker than that in other CAQDAS software. There''s a few reasons for this - immaturity, the limitations of cross-platform development, and using a beta-quality GUI library (wxruby). But a number of people have "highlighted" this shortcoming so I''ll make some time to try out some options in the experimental pre 1.2 releases. It seems to me there''s a few aspects to this - Using text formatting (highlighting, colouring, embolding, italicising) vs using marginal marks. The former gets messy! - Indicating a single mark (as at present) vs indicating any coding (without showing what it is) vs indicating all coding vs indicating a selectable subset of coding. - Showing all coding only in document text windows, vs showing all coding when viewing text in the context of a category window. Examples of what other software does well, as well as examples of why this is useful (eg Magnus''s "to remind me that I''ve already coded this passage without checking") welcome. Best wishes alex> r. Matti L > >
Quoting Alex Fenton <alex at pressure.to>:> So a software that > can represent all these different types of objects is going to be hard > to design, and likely complicated to use.I couldn''t agree more with you! I think the main reason for these "theory-building utilities" is to justify the high license fees of the current qualitative analysis tools. I have honestly tried to understand and use the Atlas.ti "knowledge building" feature. It is basically a stripped-down mind-mapping tool, while there are a number of tools which do better job than Atlas.ti. There is no automation to create the network for you. I personally think that if one creates such an automation, and other uses this implementation, they can not talk about qualitative research as I understand it. Which does not necessary make it bad but different.> It seems to me there''s a few aspects to this > - Using text formatting (highlighting, colouring, embolding, > italicising) vs using marginal marks. The former gets messy! > - Indicating a single mark (as at present) vs indicating any coding > (without showing what it is) vs indicating all coding vs indicating a > selectable subset of coding. > - Showing all coding only in document text windows, vs showing all > coding when viewing text in the context of a category window.These are excellent solutions. To avoid messy document view, you could use just one type of highlighting (color, underline or whatever) and show the effective codes with roll-on-tooltip style if supported by wxRuby implementation. If not, there could be an textarea showing the codes for the selected (cursor) position. There could be different colors for different number of overlapping segments (e.g. green = 1 segment, blue = 2 overlapping segments, red = 3 layers etc.). This way the analyser could easily see the parts she/he has already worked on. To make the view less messy (and implementation more complicated :-), the analyser could select which codes are shown. This way the analyser could show and concentrate on the codes which are relevant for the current phase of the analysis. r. Matti L
Hi! Concerning the various possibilities of representing coding, I for one very much like marginal markings. I believe this is related to the way we code - I tend to code passages that are a few lines up to some 25 lines long, and then collect the coded passages to do a closer reading and analysis but with other procedures and tools than coding. However, I imagine that if you code shorter passages, and this coding is the main analytical tool, margin marks could get very messy. On the other hand, wouldn''t any marking become very messy in this case? I do very much agree that the complicated features of for instance Atlas.ti is of limited use, and that is not what we would like weft to become...:) By the way, while talking about development, the possibility to add a memo to a specific coded passage would fit my way of working very well!! I neeed to comment on passages as well as assigning them a category or code, and it would be very nice to be able to do that with the same tool as I code with. Regards, Magnus Larsson Matti Lattu wrote:>Quoting Alex Fenton <alex at pressure.to>: > > > >>So a software that >>can represent all these different types of objects is going to be hard >>to design, and likely complicated to use. >> >> > >I couldn''t agree more with you! I think the main reason for these >"theory-building utilities" is to justify the high license fees of the >current qualitative analysis tools. > >I have honestly tried to understand and use the Atlas.ti "knowledge >building" feature. It is basically a stripped-down mind-mapping tool, while >there are a number of tools which do better job than Atlas.ti. There is no >automation to create the network for you. I personally think that if one >creates such an automation, and other uses this implementation, they can not >talk about qualitative research as I understand it. Which does not necessary >make it bad but different. > > > >>It seems to me there''s a few aspects to this >>- Using text formatting (highlighting, colouring, embolding, >>italicising) vs using marginal marks. The former gets messy! >>- Indicating a single mark (as at present) vs indicating any coding >>(without showing what it is) vs indicating all coding vs indicating a >>selectable subset of coding. >>- Showing all coding only in document text windows, vs showing all >>coding when viewing text in the context of a category window. >> >> > >These are excellent solutions. To avoid messy document view, you could use >just one type of highlighting (color, underline or whatever) and show the >effective codes with roll-on-tooltip style if supported by wxRuby >implementation. If not, there could be an textarea showing the codes for the >selected (cursor) position. > >There could be different colors for different number of overlapping segments >(e.g. green = 1 segment, blue = 2 overlapping segments, red = 3 layers >etc.). This way the analyser could easily see the parts she/he has already >worked on. > >To make the view less messy (and implementation more complicated :-), the >analyser could select which codes are shown. This way the analyser could >show and concentrate on the codes which are relevant for the current phase >of the analysis. > >r. Matti L >_______________________________________________ >weft-qda-users mailing list >weft-qda-users at rubyforge.org >http://rubyforge.org/mailman/listinfo/weft-qda-users > >
Matti Lattu wrote:> To avoid messy document view, you could use > just one type of highlighting (color, underline or whatever) and show the > effective codes with roll-on-tooltip style if supported by wxRuby > implementation. If not, there could be an textarea showing the codes for the > selected (cursor) position. >Thanks for the suggestions. Hadn''t thought of using tooltips or a secondary textarea or list showing applied coding.> There could be different colors for different number of overlapping segments > (e.g. green = 1 segment, blue = 2 overlapping segments, red = 3 layers > etc.). This way the analyser could easily see the parts she/he has already > worked on. >I like this too. I would really like to do this with text background colour, similar to highlighting in Word etc packages, but WxRuby doesn''t support it. cheers alex