Research / Journal Paper Writing in a simple way

Main ideas / lessons from the video

• Writing a journal paper is “easy” if your research idea and problem statement are good—you don’t need to feel intimidated by the process or by publishing in reputed journals.
• A strong paper starts with proper problem selection and method selection, which are determined through literature review.
• A good paper should be structured with the right components:
  • Title, Abstract, Keywords, Introduction, Contributions, Related Work, Methodology, Experiments, Results, Discussion, Conclusion, References
• The presenter emphasizes choosing the best existing approach (for performance analysis) or proposing novel contributions (for new methods), and demonstrating results using metrics.
• The video also includes practical “do/don’t” publishing advice, especially about predatory or paid “general publication” demands and handling submission/document sharing.

---

“Do / Don’t” instructions (publishing and preparation)

Do

• Do a good literature review
  • Read existing/reputed journal papers, textbooks, and published work.
  • Continuously write small portions (suggested 10–20 lines per day) toward your paper.
• Write down methodology in a notebook
• Prefer passive voice when writing the paper (instead of active voice).
• Use an evidence-based approach to decide “best method”
  • Use evaluation metrics such as time complexity and space complexity in technical contexts.
• Build strong, technical contributions (4–5 points), not generic statements.

Don’t

• Don’t pay money to “general publication”
  • The presenter claims most reputed journals are free, typically offering subscription and open access options.
  • If someone demands payment for publication, the presenter suggests skipping/avoiding it.
• Avoid retraction issues
  • The presenter advises avoiding actions that might trigger retraction risk (stated as “avoid the first and third point” earlier in the video).
• Don’t share/upload your manuscript during the period until publication
  • Example given: avoid uploading to online tools for similarity/plagiarism checks (e.g., “PLM checking” in tools) before publication.

---

Core methodology for deciding what to put in your paper (the “start” logic)

The video uses a guiding analogy:

To publish is like to travel—you first ask: “Where do I start?” In a paper, that means:

Step 1: Identify the problem statement

• Example used: 3 + 4
• Expand to bigger datasets/problems for testing method performance.
• In general: define what the task/problem is (and ensure it’s meaningful).

Step 2: Identify the existing methods/approaches

• Example used: choose multiple solution categories (e.g., kid/adult/calculator)
• In technical examples: list known methods (example for encryption: symmetric vs asymmetric, mentioning algorithms such as RSA, ECC, etc.).

Step 3: Evaluate methods using metrics and pick the best

• The video distinguishes:
  • Metrics = the main performance measures used to judge outcomes (e.g., time complexity/space complexity; taste; accuracy).
  • Parameters = the experimental settings/inputs you vary (e.g., dataset size, k value, number of ingredients; BPP; compression ratio).
• It suggests you should evaluate performance by numeric results and present comparative outcomes.

---

Detailed paper structure: what “must be there” (with suggested constraints)

1) Title

• Prefer a title that signals one of:
  • Novel framework/new method, or
  • Performance analysis / comparative study.
• The presenter says reviewers first notice “innovation” from the title.
• Even in performance analysis/review-like work, contributions must still be new
  • e.g., new applications and/or new datasets.

2) Abstract (target: 200–250 words)

Must include:

• Problem statement
• Objective
• Motivation (reasons this work is necessary)
• Justification via numerical results (e.g., accuracy around a specific %)
• Best feature / future value of the proposed/compared methods
  • e.g., 1 line each summarizing the best characteristic(s) of top methods.

Also:

• Avoid abstracts that are too long:
  • The presenter claims submission portals may reject abstracts over 250 words.
  • Very long abstracts can lead to negative reviewer perception.

3) Keywords

• Purpose: help people find your paper by area/sub-area/method/problem.
• Use proper forms (expansion suggestion):
  • Don’t keep short forms like “DES” in title/keywords; expand (e.g., Data Encryption Standard / Advanced Encryption Standard).
• Mention technique/task terms clearly.
• Avoid meaningless abbreviations.

4) Introduction (suggested: about two paragraphs)

• Must be research-oriented, not textbook/basic definitions.
• Structure:
  • Paragraph 1: research context (e.g., “in the current digital world…”)
  • Paragraph 2: motivation + justification framing (the presenter later repeats these as separate ideas, but emphasizes research orientation)

5) Motivation + Justification (each as one paragraph)

• Motivation: why this work is necessary (reasons/problems in the field)
• Justification: expected/achieved benefits/outcomes after performing the research

6) Contributions (strong, technical, 4–5 points)

• Must be specific technical contributions (examples given):
  • New dataset proposed
  • Applying methods to real clinical/realtime data (as a contribution, not just generic comparisons)
• Avoid weak contribution claims like:
  • “A comparative performance analysis was done” (considered unnecessary/generic)

7) Related Work

• Suggestion: cite 25–30 papers
• For each cited paper, write about 4–5 lines covering:
  • Problem statement
  • Method
  • Merits and limitations
  • Experimental approach
• Emphasis on citation style:
  • Use proper author-based citation phrasing (avoid awkward “paper number presented…” style).
• End of related work:
  • Include a characteristic comparison table
  • Reviewers/editors look for it (compare inputs/datasets, preprocessing, feature extraction, classification techniques, strengths, limitations, outcomes, etc.).

8) Outline / Organization of the paper

• Provide an overall technical diagram (not a simple flowchart).
• Diagram should tell a “technical story” of what the paper includes (the presenter compares it to a movie trailer).

9) Method(s)

• If it’s performance analysis: suggest using about 7 existing methods
• If it’s a proposed new method: explain your own method in depth
• For each method, include:
  • Concept
  • Technical in-depth diagram
  • Mathematical formulation
  • Technical pseudocode written by yourself (not generic/paste boilerplate)
• Use a math editor for equations/formulas (avoid copy-pasting raw formulas).

10) Experimental design

• Should describe the experimental procedure like a “recipe”:
  • What data was used and how the experiment was conducted
• Include:
  • Dataset description
  • Experimental setup with parameters (often as a table)

11) Performance evaluation

• Must demonstrate technical novelty
  • If novelty is missing, reviewers may reject the paper (as claimed).
• The presenter recommends:
  • Use at least 10 performance metrics
  • Present results as tables with exact numeric values
  • Add discussion for each table

12) Results discussion

• Discuss what the numbers show / observations:
  • The presenter compares it to a doctor interpreting a scan report (normal vs abnormal type reasoning).

13) Conclusion

Must include:

• Specific findings
• Pros/merits and cons/limitations
  • The presenter says reviewers may ask what limitations exist.
• Optionally include future work/directions
• Avoid unnecessary stories; keep conclusion aligned with results.

14) References

• References must be complete:
  • authors, title, journal/conference, volume, pages, year
  • DOI/link if available
  • conference location and country for conference papers
• Also mention tools/websites used
• Thank tools like software used for writing/presenting (as the presenter suggests).

---

Practical recommendations for what kind of first/next papers to write

• Start with a performance analysis paper of existing methods.
• After you become strong with that, write new method papers:
  • either modify an existing method,
  • fuse best parts of multiple methods,
  • or propose a novel framework with new contributions.

---

Speakers / sources featured

• Speaker: “SP Raja” (the presenter; name appears near the end of the subtitles).
• No other specific sources (authors, papers, books, journals, or websites) are named in the provided subtitles—only general references to “reputed journals,” “textbooks,” and examples like algorithms (DES/AES/RSA/ECC) are mentioned.